Jeff Rush wrote:
In researching the state of packaging, I've been reading the archives and all
the bug reports filed against distutils.
I'd like though to get some examples of particularly troublesome uses of
setup.py, to pull together and propose some changes to make their use case a
bit
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 2008-03-18 18:05, [EMAIL PROTECTED] wrote:
I'm reviving a very old thread based on discussions with Martin at pycon.
Sent: Monday, 23 July 2007 5:12 PM
Subject: Re: [Distutils] distutils.util.get_platform() for Windows
Rather than forcing everyone to read the context, allow me to
... encouraged in __3.x guidelines__ to ...: I presume although I've not
found them yet that there is some kind of document for developers titled
something like, how to migrate your Python code from 2.x to 3.x. That
document would be a logical place for advice and consideration of the
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have a 64bit version
of Windows available to
-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
Looking at http://docs.python.org/lib/module-os.html, I find the following:
name
The name of the operating system dependent module imported. The
following names have currently been registered: 'posix', 'nt', 'mac',
'os2', 'ce', 'java', 'riscos'.
This implies that there's a
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 10:18 PM 3/19/2008 -0600, zooko wrote:
The fact that easy_install creates a site.py that changes the
semantics of PYTHONPATH is probably the most widely and deservedly
hated example of this kind of thing [2].
Yep, this was an unfortunate side effect of eggs growing outside
their original
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
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in
-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
Looking at http://docs.python.org/lib/module-os.html, I find the following:
name
The name of the operating system dependent module imported. The
following names have currently been registered: 'posix', 'nt', 'mac',
'os2', 'ce', 'java', 'riscos'.
This implies that
On 2008-03-20 13:55, M.-A. Lemburg wrote:
On 2008-03-20 13:42, Thomas Heller wrote:
M.-A. Lemburg schrieb:
About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have a
Martin v. Löwis writes:
I don't think any of the core committers is qualified to write such
a document. Instead, it would have to be written by people who
*actually* ported a project from 2 to 3 in some form.
Note that this is precisely the kind of experience Skip Montanaro is
talking
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
Jeff Rush wrote:
2. If we moved PyPI to serve exclusively over https, for integrity
reasons, would this have a major negative impact?
Given that urllib2 doesn't support https through a proxy, it would
probably cause a problem for easy_install, etc. :-)
We had to create a custom
Dave Peterson wrote:
I agree. Let's get that setuptools wiki started and start documenting
some of these ideas as a roadmap so that anyone who wants to help out
has an idea of what to work on, or factor into what they're currently
working on.
Anyway, since Enthought is already
I don't think any of the core committers is qualified to write such a
document. Instead, it would have to be written by people who
*actually* ported a project from 2 to 3 in some form.
Stephen Note that this is precisely the kind of experience Skip
Stephen Montanaro is
On 20/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Actually, this information is VERY helpful. It makes it blindingly
obvious to me now that the difference between loving and hating
setuptools is whether you're *intentionally* using it, or whether it
shows up in your ecosystem
Jeff Rush wrote:
Dave Peterson wrote:
I agree. Let's get that setuptools wiki started and start
documenting some of these ideas as a roadmap so that anyone who wants
to help out has an idea of what to work on, or factor into what
they're currently working on.
Anyway, since Enthought
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
At 10:08 PM 3/20/2008 +, [EMAIL PROTECTED] wrote (off-list):
No, but in no situation, except one (where I was extremely pressed
for time) was I actually attempting to use setuptools to use any of
its features. My experience of it is: If a project uses distutils
or apt, installation
Just a thought. What I'd really like to see is a quick 5 / 10 minute
screen-cast of using setup tools. I've been looking for one for a
couple of weeks but haven't found,
Something like this buildout example, perhaps :
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
33 matches
Mail list logo
