On Mar 28, 2009, at 9:33 AM, Eric Smith wrote:
To be concrete, I think distutils should support (among other things):
- entry points for plugins
- entry points as used for producing console and windowed "scripts"
This strikes me as a nice-to-have, but:
1. I don't think they're two distinct fea
2009/3/29 Stephen J. Turnbull :
> I really don't see how that kind of thing can be easily supported by a
> Python module maintainer, unless they're also the downstream packager.
Almost none. But in my understanding, that's not what most linux
packagers vendors ask about - they will handle the dep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 28, 2009, at 10:10 AM, Stephen J. Turnbull wrote:
I really don't see how that kind of thing can be easily supported by a
Python module maintainer, unless they're also the downstream packager.
They simply can't. As a package developer, I'd
Eric Smith writes:
> I was just pointing out that bdist_rpm has users, and it's not likely to
> be abandoned.
OK, I see. I don't think there's a reason to remove useful
functionality from the stdlib, unless it's clearly superseded by a
similar module.
> I don't see how they differ. It's def
Stephen J. Turnbull wrote:
Eric Smith writes:
> And I personally use bdist_rpm for my work, which I distribute to a farm
> of servers under my control. So no doubt it's used.
Sure, but use for internal distribution is very different from to
problem its being asked to solve now, isn't it? I
2009/3/28 Stephen J. Turnbull :
>
> Sure, but use for internal distribution is very different from to
> problem its being asked to solve now, isn't it? IIUC, you're
> basically using RPM as an installer for a standalone application,
> where you set policy at both ends, packaging and installation.
Eric Smith writes:
> And I personally use bdist_rpm for my work, which I distribute to a farm
> of servers under my control. So no doubt it's used.
Sure, but use for internal distribution is very different from to
problem its being asked to solve now, isn't it? IIUC, you're
basically using RP
Mark Hammond gmail.com> writes:
>
> As mentioned, it isn't really a natural fit - but regardless, py2exe is
> struggling to maintain itself at the moment...
It is the first auto-maintained package I have ever heard of :-)
Regards
Antoine.
___
Pyth
On 28/03/2009 7:49 AM, gl...@divmod.com wrote:
Perhaps bdist_wininst/_msi could be donated to the
py2exe project if they would be willing to maintain it, and the new
project for _deb and _rpm could be called "py2packman" or something.
As mentioned, it isn't really a natural fit - but regardless
Martin v. Löwis wrote:
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
I think that conclusion is invalid: just because the distributi
I do think that it's relevant that the respective operating system
packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not
very useful to have a bdist_deb that nobody actually builds debs with.
I think that conclusion is invalid: just because the distributions don't
use it doesn't
On 2009-03-27 21:49, gl...@divmod.com wrote:
>
> On 07:59 pm, fdr...@acm.org wrote:
>> I'm actually in favor of removing the bdist_* from the standard
>> library, and allowing 3rd-party tools to implement whatever they need
>> for the distros. But I don't think what you're presenting there
>> sup
gl...@divmod.com schrieb:
> On 07:59 pm, fdr...@acm.org wrote:
>>I'm actually in favor of removing the bdist_* from the standard
>>library, and allowing 3rd-party tools to implement whatever they need
>>for the distros. But I don't think what you're presenting there
>>supports it.
>
> I do thi
13 matches
Mail list logo
