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 never
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 various things
-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
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 the many
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 rename the
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 written
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 you
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 care. I've
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
known
-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
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? If I
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
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 classifiers
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
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 / .tgs
-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(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
-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
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 use
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.
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 the
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
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.
Note that
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
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 are
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
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%+
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
| programs.
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 simpler
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 so; if
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
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 true
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 the
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 between
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 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
-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 while. If
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 tree of
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
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
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 setup.py,
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
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 it
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 discussion of
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 that.
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 be
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 (from the
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
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
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 ...
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 not
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 unpack
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 support
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 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 certain
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__ import
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 statement, or is
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 egg support in
-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 bootstrap
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
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 split
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,
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
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
63 matches
Mail list logo
