In an attempt to help this thread reach some sort of resolution,
here's a collection of arguments against and in favour of setuptools
in 2.5. My conclusions are at the end.
The arguments against:
- Someone should instead just fix distutils.
Right. And the amount of yelling if distutils ch
M.-A. Lemburg wrote:
>There's really nothing wrong with the standard distutils
>two step process:
>1. download and unzip the source file
On windows, the closest thing to a standard unzip is winzip.
I have recently found several zip files aimed at windows users which
winzip could not open, thoug
Anthony Baxter wrote:
> - Multiple installs of different versions of the same package,
> including per-user installs.
yeah, but where is the documentation on how this works ? phillip points
to a 30-page API description, which says absolutely nothing whatsoever
about the files I'm going to find o
Anthony Baxter wrote:
> And now let's look at some of the stuff that setuptools gives us:
>
> - We have a CPAN-type system
I think it is unfair (to Richard Jones) to attribute this to
setuptools. We already have a CPAN-type system: the Cheeseshop.
What setuptools adds is roughly the CPAN shell (
On Thursday 20 April 2006 16:30, Martin v. Löwis wrote:
> I think it is unfair (to Richard Jones) to attribute this to
> setuptools. We already have a CPAN-type system: the Cheeseshop.
> What setuptools adds is roughly the CPAN shell (ie. CPAN.pm
> or however it is implemented). Actually, I think i
Thanks for posting an excellent summary, Anthony.
For the record, I'm taking full responsibility for the decision that
setuptools is going in. Having read much (though not all) of the
endless bitching, and the responses from Phillip and others in
defense, I still believe it's the right decision. I
Anthony Baxter wrote:
> Not without a lot of the other stuff that's in setuptools.
>
>> That is says from itself that it is version 0.7a1dev-r45536
>> doesn't help to reduce that fear.
>
> It's had _two_ _years_ of quite active development, so the version
> number of 0.7 is hardly a good indica
On Thursday 20 April 2006 17:51, Martin v. Löwis wrote:
> > He's written code on _top_ _of_ _distutils_. How is this bad?
>
> It makes distutils an implementation detail of setuptools. What
> little development distutils has seen will stop; all fixes will
> go into setuptools directly. Users will b
Anthony Baxter wrote:
> I also don't think it will be the "death" of distutils. I think that
> over time the two pieces of code will become closer together -
> hopefully for Python 3.0 we can formally merge the two.
I was hoping that for Python 3.0, we could get around to unkludge the
sys.path/me
Fredrik Lundh wrote:
> Anthony Baxter wrote:
>
>> I also don't think it will be the "death" of distutils. I think that
>> over time the two pieces of code will become closer together -
>> hopefully for Python 3.0 we can formally merge the two.
>
> I was hoping that for Python 3.0, we could get ar
On Thursday 20 April 2006 18:18, Fredrik Lundh wrote:
> I was hoping that for Python 3.0, we could get around to unkludge
> the sys.path/meta_path/path_hooks/path_importer_cache big ball of
> hacks, possibly by replacing sys.path with something a bit more
> intelligent than a plain list.
Oh please
On 4/20/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Thursday 20 April 2006 18:18, Fredrik Lundh wrote:
> > I was hoping that for Python 3.0, we could get around to unkludge
> > the sys.path/meta_path/path_hooks/path_importer_cache big ball of
> > hacks, possibly by replacing sys.path with so
> The arguments against:
One more:
- Installing a package means dropping files in the system without
any kind of record keeping.
It should learn from the techniques applied in other well-known
package managers (RPM, DPKG, whatever) to keep track of what's
happening in the system.
--
Gu
Anthony> Finally, I'd like to point out that I think some of the
Anthony> hostility towards Phillip's work has been excessive. He's done
Anthony> an amazing amount of work on this (look at the distutils-sig
Anthony> archive for the last two years for more), and produced
Anthony
[EMAIL PROTECTED] wrote:
> Maybe they know something we don't.
oh, please. it's not like people like myself and MAL don't know anything
about package distribution...
(why is it that people who *don't* distribute stuff are a lot more im-
pressed by a magic tool than people who've spent the last
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>>Maybe they know something we don't.
>
> oh, please. it's not like people like myself and MAL don't know anything
> about package distribution...
>
> (why is it that people who *don't* distribute stuff are a lot more im-
> pressed by a magic tool
Ian Bicking wrote:
> And now for a little pushback the other way -- as of this January
> TurboGears has served up 100,000 egg files (I'm not sure what the window
> for all those downloads is, but it hasn't been very long). Has it
> occurred to you that they know something you don't about distribu
Fredrik Lundh wrote:
> - they're currently discussing whether to use stricter version requirements
> for individual components, to increase the chance that people end up using
> a combination that someone else has actually tested.
I don't think setuptools version requirements are enough to ensure
Ian Bicking wrote:
> I don't think setuptools version requirements are enough to ensure the
> integrity of all pieces of a complex system will work together.
> Figuring out a self-consistent set of packages to work together is
> something that is rather independent of any particular package, and
Ian Bicking wrote:
> Fredrik Lundh wrote:
>> [EMAIL PROTECTED] wrote:
>>> Maybe they know something we don't.
>> oh, please. it's not like people like myself and MAL don't know anything
>> about package distribution...
>>
>> (why is it that people who *don't* distribute stuff are a lot more im-
>>
>>And now for a little pushback the other way -- as of this January
>>TurboGears has served up 100,000 egg files (I'm not sure what the window
>>for all those downloads is, but it hasn't been very long). Has it
>>occurred to you that they know something you don't about distribution?
>>ElementT
On 4/20/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I wonder why people always seem to imply that installing
> packages has never worked before there was setuptools.
>
> There's really nothing wrong with the standard distutils
> two step process:
>
> 1. download and unzip the source file
>
> 2.
At 11:49 PM 4/20/2006 +0100, Paul Moore wrote:
>It's possible that (1) can be solved by making *all* distutils
>installs create egg metadata.
This is already planned to be addressed in Python 2.5, via the
install_egg_info added to the distutils. The implementation is already in
the trunk, but n
At 11:53 PM 4/20/2006 +0200, M.-A. Lemburg wrote:
>Only after endless discussions, Phillip added some weird
>--long-option-name-that-no-one-can-remember to the setuptools
>"install" command that restores the standard distutils behavior
>which should be the default anyway.
And later, I also made it
Paul Moore wrote:
> 2. Distributors will supply .egg files rather than bdist_wininst
> installers (this is already happening).
Really people should at least be uploading source packages in addition
to eggs; it's certainly not hard to do so.
Perhaps a distributor quick intro needs to be written f
Hello,
just one more datapoint to help Phillip change his mind on the default install
behavior and the monkeypatching: this is actually hurting adoption of
setuptools.
example: the matplotlib folks wanted to add *optional* setuptool support, but
this is impossible because simply importing setu
On Thu, 2006-04-20 at 23:53 +0200, M.-A. Lemburg wrote:
> There's really nothing wrong with the standard distutils
> two step process:
>
> 1. download and unzip the source file
>
> 2. run "python setup.py install"
The only thing I'll add (other than put me in the "just make it work and
tell me
At 07:33 PM 4/20/2006 -0400, Barry Warsaw wrote:
>The only thing I'll add (other than put me in the "just make it work and
>tell me what to do" camp ;) is that I really want a simple way to say
>"do not install into the system Python, put everything over here and I
>will fiddle with my environment
On Thu, 2006-04-20 at 19:43 -0400, Phillip J. Eby wrote:
> >I may be way out of date with the state of the art these days, but in
> >the past, I've had a difficult time making this work for Mailman. For
> >example, at various times we've had to distribute our own email package
> >and Asian codecs
At 11:08 PM 4/20/2006 -0400, Barry Warsaw wrote:
>Question out of total ignorance: say I get a 3rd party package that has
>a standard distutils setup.py but knows nothing of setuptools. Say I
>install my own copy of setuptools (or have Python 2.5). Can that 3rd
>party package still be installed "
At 01:18 AM 4/21/2006 +0200, Baptiste Carvello wrote:
>So instead, they ask the setuptool users to use
>python -c "import setuptools; execfile('setup.py')" install
>That's just too bad, and much more confusing than setup.py install_egg !
Actually, the setuptools users just run "easy_install matplo
On Friday 21 April 2006 03:31, Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
> > Maybe they know something we don't.
>
> oh, please. it's not like people like myself and MAL don't know
> anything about package distribution...
>
> (why is it that people who *don't* distribute stuff are a lot more
Thanks for all the great information Phillip.
On Thu, 2006-04-20 at 23:33 -0400, Phillip J. Eby wrote:
> Anyway, that's a complete digression from the question you asked. As long
> as Mailman doesn't depend on building something like Numeric or Twisted,
> you can probably wrap it in easy_insta
On 4/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > 2. Distributors will supply .egg files rather than bdist_wininst
> > installers (this is already happening).
>
> Really people should at least be uploading source packages in addition
> to eggs; it's certainly not hard to do
Phillip J. Eby wrote:
> You seem to believe that there are other
> things more important than making things Just Work for this audience.
While it's clearly a good thing when something "just
works", I don't think that this should be the only goal.
Just as important to my mind -- probably even more
On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> - they're currently discussing whether to use stricter version requirements
> for individual components, to increase the chance that people end up using
> a combination that someone else has actually tested.
That makes me quite nervous. While
Phillip J. Eby wrote:
> So, this is a nice
> example of how complex it can be to extend the distutils in ways that don't
> break random popular packages.
It's probably also an example of what happens when
something doesn't have a well-documented extension
interface -- nobody can tell what's an i
Paul Moore wrote:
> Well, having 2 versions of a module installed and
> knowing that which one is in use depends on require calls which get
> issued at runtime worries me far more.
There's also the problem of having module A which requires
version 2.0 or earlier of Z, and B which requires 2.1 or l
At 12:51 PM 4/21/2006 -0400, Jim Jewett wrote:
>Phillip J. Eby wrote:
>
> > Such packages may have customized their installation process
> > by extending the distutils, *without* overriding get_outputs(). Since few
> > people actually use the --record option for anything important, nobody
> > noti
On 4/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:51 PM 4/21/2006 -0400, Jim Jewett wrote:
> >Phillip J. Eby wrote:
> > > As for --install-data
> > > ... one of the pre-existing distutils extensions ...
> > Use of a third-party extension (that isn't mentioned
> > in the docs [2.3]) is
Paul Moore wrote:
> And no, I don't want to install the 2 versions side-by-side. Ian
> Bicking complained recently about the "uncertainty" of multiple
> directories on sys.path meaning you can't be sure which version of a
> module you get. Well, having 2 versions of a module installed and
> knowing
Ian Bicking wrote:
> For instance, if you really want to be confident about how your libraries
> are layed out, this script is the most reliable way:
> http://peak.telecommunity.com/dist/virtual-python.py
note the use of "this script is the most reliable way", not "something
like this script", or
At 12:34 PM 4/22/2006 +0200, Fredrik Lundh wrote:
>Ian Bicking wrote:
>
> > For instance, if you really want to be confident about how your libraries
> > are layed out, this script is the most reliable way:
> > http://peak.telecommunity.com/dist/virtual-python.py
>
>note the use of "this script is
Phillip J. Eby wrote:
> >(frankly, do you think there's any experienced developer out there
> >whos first thought when asked the question "how do I create a tightly
> >controlled Python environment" isn't either "can I solve this by tweaking
> >sys.path in my application?" or "disk space is cheap,
Anthony Baxter wrote:
> In an attempt to help this thread reach some sort of resolution,
> here's a collection of arguments against and in favour of setuptools
> in 2.5. My conclusions are at the end.
Thanks for the summary. I'd like to add some important aspects
(for me at least) that are missi
M.-A. Lemburg wrote:
> Anthony Baxter wrote:
>
>>In an attempt to help this thread reach some sort of resolution,
>>here's a collection of arguments against and in favour of setuptools
>>in 2.5. My conclusions are at the end.
>
>
> Thanks for the summary. I'd like to add some important aspects
46 matches
Mail list logo
