Paul Moore wrote:
Is there anything I can do to get it applied, or should I just leave
it now for someone to decide if they care enough? (As it's a library
change, I don't know to what extent the no API changes after the next
alpha rule will apply).
I'm looking into it now - assuming it
On 19/03/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm currently working on an addition to pkgutil to provide this type
of function. I'm considering going a little further (adding functions
to get a file-like object, test for existence, and list available
resources, modelled on
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
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 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
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
On Wed, 2008-03-19 at 22:18 -0600, zooko wrote:
1. The very notion of package dependency resolution and
programmable or command-line installation of packages at the language
level is a bad notion.
This can't really be the case. If the existence of such
functionality at the
Paul Moore wrote:
On 20/03/2008, zooko [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
On 20/03/2008, Jeff Rush [EMAIL PROTECTED] wrote:
Paul Moore wrote:
On 20/03/2008, zooko [EMAIL PROTECTED] 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
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
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
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 19/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
I don't particularly want to use undocumented functions - even within
the module that defines them.
Er, you could always document them, you know. I just didn't get
around to it before the whole setuptools flap of 2005 wiped out my
At 09:43 AM 3/19/2008 +, Paul Moore wrote:
On 19/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
I don't particularly want to use undocumented functions - even within
the module that defines them.
Er, you could always document them, you know. I just didn't get
around to it
On Mon, Mar 17, 2008 at 2:19 PM, zooko [EMAIL PROTECTED] wrote:
4. The standard Python library includes a tool to find and read
resources (other than Python modules) that came bundled in a Python
package.
Consider, for example, this snippets of code in Nevow:
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
On 19/03/2008, Guido van Rossum [EMAIL PROTECTED] wrote:
On Mon, Mar 17, 2008 at 2:19 PM, zooko [EMAIL PROTECTED] wrote:
4. The standard Python library includes a tool to find and read
resources (other than Python modules) that came bundled in a Python
package.
I think we're pretty
At 05:04 PM 3/19/2008 +, Paul Moore wrote:
On 19/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
It's so that you can get loaders for modules that aren't imported yet
-- and your code would need to handle this case too.
Well, technically, it need not, as I don't *need* to implement the
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 Mar 19, 2008, at 3:52 PM, Marius Gedminas wrote:
On Wed, Mar 19, 2008 at 03:37:59PM -0400, Jim Fulton wrote:
On Mar 18, 2008, at 2:51 PM, Marius Gedminas wrote:
...
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Could you be specific?
I suppose I was
On Mar 18, 2008, at 2:51 PM, Marius Gedminas wrote:
...
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Could you be specific? It has worked pretty well for us. It makes it
hard to provide software in zip files, but that seems overrated. In
particular, I
On Wed, Mar 19, 2008 at 03:58:58PM -0400, Jim Fulton wrote:
On Mar 19, 2008, at 3:52 PM, Marius Gedminas wrote:
On Wed, Mar 19, 2008 at 03:37:59PM -0400, Jim Fulton wrote:
On Mar 18, 2008, at 2:51 PM, Marius Gedminas wrote:
...
os.path.join(os.path.dirname(__file__), 'foo') just has too many
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
On Mon, Mar 17, 2008 at 08:19:11PM +, Paul Moore wrote:
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).
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
On 18/03/2008, Marius Gedminas [EMAIL PROTECTED] wrote:
+1 for something like this in the stdlib.
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Hmm, maybe I should put some of my money where my mouth is. I'd be
willing to work up a patch to add some key items
At 09:01 PM 3/18/2008 +, Paul Moore wrote:
On 18/03/2008, Marius Gedminas [EMAIL PROTECTED] wrote:
+1 for something like this in the stdlib.
os.path.join(os.path.dirname(__file__), 'foo') just has too many
problems.
Hmm, maybe I should put some of my money where my mouth is. I'd 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 18/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Sure... though I doubt you'll have much luck, unless you drop
support for resource_filename, and stick with
resource_string()/resource_stream(). Supporting resource_filename()
for zipfiles inherently requires that you extract the file
At 10:44 PM 3/18/2008 +, Paul Moore wrote:
Someone should document these new functions :-( Was it you that added
them?
Yes, and it was specifically to start pulling some of that stuff out
of pkg_resources so it'd be more widely available.
Assuming it was, what's the simplegeneric function
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 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
On 17/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
The PEP suggests that other package managers also benefit. How do they
benefit if the bootstrap script installs setuptools?
Because those other package managers depend, in fact, on setuptools,
or at least pkg_resources... which was why
On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore [EMAIL PROTECTED] wrote:
On 17/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
The PEP suggests that other package managers also benefit. How do they
benefit if the bootstrap script installs setuptools?
Because those other package managers
On 17/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
Personally, I have no problem per se with including setuptools in the
stdlib. Maybe that means I miss the subtle benefit of this approach...
Did you review setuptools and can vouch that it is written cleanly,
follows the coding style,
But I don't see any practical difference with including setuptools and
including a module that installs setuptools. Would you be happy with
the standard library including a module whose sole function was to
install a package that you weren't happy to include directly in the
standard library?
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
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
Guido van Rossum wrote:
On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore [EMAIL PROTECTED] wrote:
I'm +lots on someone giving a clear explanation of the meaning and
interrelationship of the various terms involved in this discussion
(setuptools, easy_install, pkg_resources, eggs, package
At 02:44 PM 3/17/2008 -0500, Jeff Rush wrote:
Guido van Rossum wrote:
On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore [EMAIL PROTECTED] wrote:
I'm +lots on someone giving a clear explanation of the meaning and
interrelationship of the various terms involved in this discussion
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
56 matches
Mail list logo
