zooko:
> Um, isn't this tool called "unzip"? I have done this -- accessed the
> source code -- many times, and unzip suffices.
The type of issue I ran into with eggs is when you get an exception
with a trace that includes an egg, you can't use the normal means to
look at the code. Instead y
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
To Paul's question: I have only installed a couple of things (and not
recently) that added their own add/remove entry. But I am not sure I would
have called them add-ons as opposed to independent applications writte
At 09:53 AM 3/21/2008 -0600, zooko wrote:
>Um, isn't this tool called "unzip"? I have done this -- accessed the
>source code -- many times, and unzip suffices.
>
>I don't know what else would be required in order to make an egg into
>"a standard distutils-style installation".
You also have to ren
On Mar 20, 2008, at 6:22 PM, Robert Brewer wrote:
> Phillip J. Eby wrote:
>> The other tool that would be handy to have, would be one that unpacks
>> eggs into standard distutils-style installation.
>
> Hear, hear. I'm an author of a couple libraries that need to
> interoperate with others. Of th
-On [20080320 19:24], Steve Holden ([EMAIL PROTECTED]) wrote:
>We need to stop protesting that our installation tools are easy enough
>and try to get behind the various platforms, be it with Windows
>installers, rpms, or other support. We probably aren't doing this
>because it's work nobody part
At 12:33 PM 3/21/2008 +, Paul Moore wrote:
>On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > The standard (and to me, preferable) way of dealing with such
> things is to
> > have an 'installation manager' that can reinstall as well as delete and
> > that has a check box for variou
On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> However, this Windows user, and I expect most, do NOT expect add-ons
> (things under the /Pythonx.y tree) to show up in the add/remove list.
That's an interesting counterpoint to my comments. I presume from this
that you dislike (and/or neve
Janzert wrote:
> Since there seems to be a fair number of negative responses to
> setuptools, I just wanted to add a bit of positive counterbalance. I'm
> just a random python user that happens to track python-dev a bit, so
> take all this with the realization that I probably shouldn't have much
>
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [a long message]
>
> I'm back at Google and *really* busy for another week or so, so I'll
> have to postpone the rest of this discussion for a while. If other
> people want to chime in please do
On Mar 20, 2008, at 7:44 AM, Tres Seaver wrote:
> Paul Moore wrote:
>> 4. Hard to use with limited connectivity. At work, I *only* have
>> access to the internet via Internet Explorer (MS based proxy). There
>> are workarounds, but ultimately "download an installer, then run it"
>> is a far simpl
"Tres Seaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Paul Moore wrote:
|
| > 1. No integration with the system packager (Windows, in my case). If I
| > do easy_install nose, then nose does not show up in add/remove
| > pro
Phillip J. Eby wrote:
> The other tool that would be handy to have, would be one that unpacks
> eggs into standard distutils-style installation.
Hear, hear. I'm an author of a couple libraries that need to
interoperate with others. Of the many eggs I've downloaded over the past
year, I'd say 80%+
At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:
> A lot of setuptools warts are driven by related design problems in the
> distutils, such as the choice to use imperative / procedural code for
> everything
If a distutils replacement is ever written, I'd like to
see it structured as a dependency g
On 2008-03-20 21:34, Paul Moore wrote:
>> Also, setuptools-based packages *can* build bdist_wininst
>> installers. (In fact, if memory serves, I added that feature at your
>> request.)
>
> I know. python setup.py bdist_wininst. And thank you for adding it.
> But again you miss my point. People
At 08:34 PM 3/20/2008 +, Paul Moore wrote:
>I then went on to say that putting dependency information in setup.exe
>and expecting users to use automatic dependency resolution encourages
>developers to omit dependency details from documentation (to an extent
>I can't quantify, but I believe is n
On 20/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 3/20/2008 +, Paul Moore wrote:
> >It's not that I object to the existence of automatic dependency
> >management, I object to being given no choice, as if my preference for
> >handling things manually is unacceptable.
>
>
At 05:55 PM 3/20/2008 +, Paul Moore wrote:
>It's not that I object to the existence of automatic dependency
>management, I object to being given no choice, as if my preference for
>handling things manually is unacceptable.
Note that easy_install has a --no-deps option, and you can make it
the
Martin v. Löwis wrote:
Martin v. Löwis wrote:
>> I'll note that I use easy_install *only* to work in *non-system*
>> locations: if I want to install Python packages to /usr/lib/python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'.
>
> This is probably not
> Actually, if someone were to develop a patch for PyPI to do this, we
> could perhaps have a "display download dependencies" link for eggs
> shown on PyPI. That way, someone who wants to do a manual download
> could get a page with links for all the required eggs, and manually
> download them
> I'll note that I use easy_install *only* to work in *non-system*
> locations: if I want to install Python packages to /usr/lib/python2.x/,
> I use the standard system installer, e.g. 'apt-get install
> python-frobnatz'.
This is probably not the Windows way of doing things (at least not how
I u
-On [20080320 05:58], Tres Seaver ([EMAIL PROTECTED]) wrote:
>I think that, warts an all, setuptools is a *huge* improvement over bare
>distutils for nearly every use case I know about.
Agreed.
I see setuptools (along with PyPI - hopefully much better in near future
though) as the Python equivale
-On [20080320 15:29], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote:
>(Trove classifiers, >although the word "trove" means nothing to me)
Isn't that something lifted from SourceForge?
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rang
At 09:44 AM 3/20/2008 -0400, Tres Seaver wrote:
>I don't know how to make this requirement compatible with using shared
>dependencies, except to make it easier for folks to download *all* the
>requirements, and later install from the local "distribution cache" (a
>directory full of .zip / .egg / .t
At 09:33 AM 3/20/2008 +, Paul Moore wrote:
>1. No integration with the system packager (Windows, in my case). If I
>do easy_install nose, then nose does not show up in add/remove
>programs. That significantly affects the way I manage my PC.
The long-term fix here is probably to have a platform
At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:
>A lot of setuptools warts are driven by related design problems in the
>distutils, such as the choice to use imperative / procedural code for
>everything: a declarative approach, with hooks for cases which actually
>need them (likely 5% of existing
Guido van Rossum schrieb:
> I was using the human interface at python.org/pypi. There are two
> prominent links at the top of the page: "Browse the tree of packages"
> and "Submit package information" followed by the 30 most recently
> changed packages.
Ah, ok. In PyPI parlance, these are "classif
Bob Kline wrote:
> Are things really that different in the non-Windows worlds? If I want
> python-nose, I run "sudo apt-get install python-nose" (and that means I
> can always remove it with "sudo apt-get remove ..."). Seems more
> similar than different (ignoring the silliness of Microsoft's
Tres Seaver wrote:
> Point taken. Of course, it isn't really a "program" at that point: it
> is an installed "add-on" to Python. However, if Windows users expect
> such add-ons to show up in the "system" list, that is good to know.
>
Are things really that different in the non-Windows worlds?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Moore wrote:
> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta-di
On 09:33 am, [EMAIL PROTECTED] wrote:
>I'll chime in here, too. I really want to like
>setuptools/easy_install, but I don't. I'll try to be specific in my
>reasons, in the hope that they can be addressed. I know some of these
>are "known about", but one of my meta-dislikes of setuptools is that
>k
On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:
> On Mar 19, 2008, at 3:23 PM, Guido van Rossum wrote:
>
> > If other people want to chime in please do so; if this is just a
> > dialog between Phillip and me I might incorrectly assume
> > that nobody besides Phillip really cares.
>
> I really ca
I was using the human interface at python.org/pypi. There are two
prominent links at the top of the page: "Browse the tree of packages"
and "Submit package information" followed by the 30 most recently
changed packages. What I was looking for was the page for a specific
package. The "Browse the tre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [a long message]
>
> I'm back at Google and *really* busy for another week or so, so I'll
> have to postpone the rest of this discussion for a whil
On Mar 19, 2008, at 3:23 PM, Guido van Rossum wrote:
> If other people want to chime in please do so; if this is just a
> dialog between Phillip and me I might incorrectly assume
> that nobody besides Phillip really cares.
I really care. I've used setuptools, easy_install, eggs, and
pkg_resour
> I don't understand PyPI all that well; it seems poor design that the
> browsing via keywords is emphasized but there is no easy way to
> *search* for a keyword (the list of all packages is not emphasized
> enough on the main page -- it occurs in the side bar but not in the
> main text).
I don't
On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
[a long message]
I'm back at Google and *really* busy for another week or so, so I'll
have to postpone the rest of this discussion for a while. If other
people want to chime in please do so; if this is just a dialog betwee
At 10:48 AM 3/19/2008 -0700, Guido van Rossum wrote:
>I don't understand PyPI all that well; it seems poor design that the
>browsing via keywords is emphasized but there is no easy way to
>*search* for a keyword (the list of all packages is not emphasized
>enough on the main page -- it occurs in th
On Tue, Mar 18, 2008 at 3:36 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote:
> >Only very few people would care about writing a setup
> >script that works with this bootstrap module; basically only package
> >manager implementers.
>
> That's
At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote:
>Only very few people would care about writing a setup
>script that works with this bootstrap module; basically only package
>manager implementers.
That's true today, sure, but as soon as it is widely available,
others are sure to want to use i
There seems to be a misunderstanding about what I am proposing we do
instead. The boostrap installer should only be powerful enough to
allow it to be used to install a real package manager like setuptools.
Maybe my use of Django as an example was confusing; I didn't actually
mean that it should be
On Tue, Mar 18, 2008 at 11:23 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote:
> >I am hoping that someone will create a simpler bootstrap module that
> >is able to download a file of pure Python code and install it, perhaps
> >by running its s
Guido van Rossum writes:
> I am hoping that someone will create a simpler bootstrap module
FWIW (I've never tried to implement one of these things) I agree with
Phillip. This is not possible in the sense you are advocating.
Anything "simpler" is simply an invitation to an unending stream of
iss
At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote:
>I am hoping that someone will create a simpler bootstrap module that
>is able to download a file of pure Python code and install it, perhaps
>by running its setup.py, assuming that it only depends on distutils
>(or other things previously instal
After reading all this, I really don't believe that adding egg
support to the stdlib at this time is the right thing to do. I am
therefore rejecting the PEP.
I am hoping that someone will create a simpler bootstrap module that
is able to download a file of pure Python code and install it, perhaps
On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> That leaves MAL, whose objections to PEP 365 centered on the API (he
> said he was "+1 on the concepts being added to the stdlib, -1 on
> adding the module in its current state"). Among other concerns, he
> wanted pkg_resources to be s
At 01:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>I have certainly personally encountered plenty of situations where I
>wasn't able to complete an egg-based install because some dependency
>was broken (e.g. not available for the Python version I was using).
That's odd -- setuptools-based insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>> >I don't think this should play games with scripts being overridden or
>> >whatever. If a
On Mon, Mar 17, 2008 at 1:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
> >On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby
> ><[EMAIL PROTECTED]> wrote:
> > > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> > > >There will be no
At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby
><[EMAIL PROTECTED]> wrote:
> > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> > >There will be no egg support in the standard library.
> >
> > Are there any qualifications on that stat
On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> >There will be no egg support in the standard library.
>
> Are there any qualifications on that statement, or is this in the
> same category as "from __future__ im
On 17/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> > Is it *wanted* that eggs are being supported by core Python?
>
> No. There will be no egg support in the standard library.
This bothers me somewhat. At a cer
At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
>There will be no egg support in the standard library.
Are there any qualifications on that statement, or is this in the
same category as "from __future__ import braces"?
___
Python-Dev mailing list
On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It should be able to download a Python-only module or package and
> > install it into site-packages (or perhaps elsewhere if so directed via
> > another optional command line flag). It should
Guido van Rossum wrote:
> It should be able to download a Python-only module or package and
> install it into site-packages (or perhaps elsewhere if so directed via
> another optional command line flag). It should support zip, tar and
> tar.gz/tgz files (and perhaps tar.bz2). It should simply unpac
On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
> >I don't think this should play games with scripts being overridden or
> >whatever. If a bootstrap script is to be installed it should have a
> >separate name. I'm
At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>I don't think this should play games with scripts being overridden or
>whatever. If a bootstrap script is to be installed it should have a
>separate name. I'm not sure what the advantage is of a bootstrap
>script over "python -m bootstrap_module
I don't think this should play games with scripts being overridden or
whatever. If a bootstrap script is to be installed it should have a
separate name. I'm not sure what the advantage is of a bootstrap
script over "python -m bootstrap_module ..." though.
The PEP suggests that other package manage
>> I thought the original proposal was to install a *binary* easy_install
>> that takes that function.
>
> What do you mean by "binary"? I thought we were talking about a
> module. Do you mean a script to be installed alongside Python itself in
> e.g. /usr/bin?
Exactly so.
> In the original
At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote:
> > Well, it might be replaced by a protracted discussion of how the
> > module should work and what its API should be, but perhaps that would
> > be a better one to have. :)
>
>Indeed, that's likely to happen :-)
>
> > So, the original proposal
> Well, it might be replaced by a protracted discussion of how the
> module should work and what its API should be, but perhaps that would
> be a better one to have. :)
Indeed, that's likely to happen :-)
> So, the original proposal (from the previous thread about this) was
> that the module
At 08:48 AM 3/17/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > So, if the consensus is that it would be better to have a module that
> > only does bootstrap installs of pure-Python eggs from PyPI, I'm
> > totally fine with tha
On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> So, if the consensus is that it would be better to have a module that
> only does bootstrap installs of pure-Python eggs from PyPI, I'm
> totally fine with that.
Let's just do this; it will avoid a protracted discussio
On Mar 16, 2008, at 8:06 PM, Phillip J. Eby wrote:
> Quick summary of the below: I'm definitely fine with doing a simpler,
> pure-bootstrap module, if there's some consensus on what should go in
> it. I just wish we could've had this discussion last year, when OSAF
> was still able to fund the w
Quick summary of the below: I'm definitely fine with doing a simpler,
pure-bootstrap module, if there's some consensus on what should go in
it. I just wish we could've had this discussion last year, when OSAF
was still able to fund the work... ;-)
At 06:13 PM 3/16/2008 -0500, Guido van Rossu
Phillip asked me to give an opinion on his pkg_resources PEP. While
the PEP is short and sweet, the pkg_resources module itself is huge
(1800 non-blank lines; 16 classes plus 5 exceptions; it exports 67
names in total according to __all__). And pkg_resources.txt is another
1700 lines of documentati
65 matches
Mail list logo
