At 09:55 AM 7/7/2010 -0300, Hugo Lopes Tavares wrote:
>Python 2.7 was released in July 3, and until now we don't have
>ez_setup.py working for that. It looks for an egg for each python
>version, and nobody has uploaded that.
>There was a guy here last month with problems to install seutptools in
>his Windows, for a similar reason.
>Is there so much problem to release bdists for Python 2.7?
>And if you come and say to download the tarball and later install, I
>was trying to use virtualenv + Python2.7 and virtualenv uses
>ez_setup.py to create virtual environments.
>Could someone upload the bdists and update ez_setup.py?
I'm still getting a proper 2.7 built and packaged for my deployment
machine. The new egg will be up soon.
I've posted this question to Stackoverflow, but didn't get a response
there so I thought I'd ask here. (This is simply a copy and paste of that
For whatever reason, my build system isn't installing one of my packages
properly. When I use yolk (from within a virtualenv), I get the following:
bin/yolk -l elig
elig - 3.1.2.dev - non-active development
How exactly does a package go from active development to non-active
Python 2.7 was released in July 3, and until now we don't have
ez_setup.py working for that. It looks for an egg for each python
version, and nobody has uploaded that.
There was a guy here last month with problems to install seutptools in
his Windows, for a similar reason.
Is there so much problem to release bdists for Python 2.7?
And if you come and say to download the tarball and later install, I
was trying to use virtualenv + Python2.7 and virtualenv uses
ez_setup.py to create virtual environments.
Could someone upload the bdists and update ez_setup.py?
I'm trying to make a buildbot for zc.buildout on various windows
The problem is that bin/buildout acts weird when it's run by the
OTOH, it's fine when running it manually (same credentials):
zc.buildout version 1.5.0dev;
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\test'.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\oltest'.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\zope-testrunner'.
Generated interpreter 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\py'.
Does anyone know why this could happen?
Adam GROSZER mailto:firstname.lastname@example.org
Quote of the day:
We can't all be heroes. Somebody has to sit on the curb and clap as they go by.
- Will Rogers
So, there won't be any package management tool shipped with Python 2.7
and users will have to download and install `setuptools` manually as
"search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
Therefore I still propose shipping bootstrap package that instruct
user how to download and install an actual package management tool
when users tries to use it. So far I know only one stable tool -
`easy_install` - a part of `setuptools` package.
The required behavior for very basic user friendliness:
1. user installs Python 2.7
2. user issues `python -m easy_install something`
3. user gets message
'easy_install' tool is not installed on this system. To make it
available, download and install `setuptools` package from
4. the screen is paused before exit (for windows systems)
Other design notes:
1. if package tries to import `easy_install` module used for
bootstrap, it gets the same ImportException as if there were no
`easy_install` at all
2. bootstrap module is overwritten by actual package when users installs it
So, do we need a PEP for that? How else can I know if consensus is
reached? Anybody is willing to elaborate on implementation?
P.S. Please be careful to reply to relevant lists
On Mon, Mar 29, 2010 at 9:37 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote:
> 2010/3/29 anatoly techtonik <techtonik(a)gmail.com>:
>> It is really hard to follow. You should at least change subjects when
>> switching topic.
> I was talking about the work going on and the decisions taken lately.
> I never change topics of threads mails when there's less than 100 mails,
> because I find it way more confusing :)
>> So, what is the verdict? Will there be a package management tool or
>> bootstrap package for it shipped with Python 2.7 or not?
> As I said in the mail you've quoted, all improvements are made in
> Distutils2. So the answer is no.
> Python 2.7b1 is due in less than a week anyways, so any new
> development on this topic will happen after.
> Basically Python 2.7 == Python 2.6 in term of packaging.
> Tarek Ziadé | http://ziade.org
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
> Besides the numerous technical issues, this is just basic decency. If
> I were PJE, I would be very mad.
I'm not mad at it being provided with a compatible API. However, I
*am* very unhappy with the fact that the version of distribute that's
being shipped with OS distributions is both packaged as (e.g.)
"python-setuptools", AND prevents people from installing the real
setuptools, even in a local directory!
So, David, I hope you've filed this as a bug report with both
Distribute and Ubuntu, and that others will do the same for any other
distribution that's shipping distribute under a misleading name and
that has this behavior.
My understanding when this was discussed previously, was that
distribute would *only* suppress the installation of setuptools
versions released *before* the corresponding version of distribute.
Also, considering how widespread the "setuptools isn't being
maintained" lie is at this point, I'm a bit concerned that some OS
distributors may have been unduly influenced by it in their switching
My understanding (and I would guess, that of the OS distributors' as
well) was *also* based on the premise that distribute was going to
track with setuptools' feature additions and bug fixes, which it
clearly has not. The 0.6c11 release (last October) fixed a rather
long list of bugs besides the one you reported; does anyone know if
the rest are actually fixed in Distribute?
-----BEGIN PGP SIGNED MESSAGE-----
I haven't found any docs (outside the code) for the
setuptools.dist.Feature, or for how it operates with the rest of the
ecosystem. Can somebody confirm or correct my understanding of them?
- - Feature instances represent optionally-included bits of the
- - Normally, features are disabled by default, and can be enabled
by passing '--with-<featurename>' to setup.py.
- - Features declared as 'standard' are enabled by default, and can be
disabled by passing '--without-<featurename>' to setup.py.
- - Features have an 'available' attribute, which can be set to False
in setup.py to disable a feature based on runtime introspection
(e.g., using sys.version_info or os.name).
- - It appears that it should be possible to pass an instance with
a '__nonzero__' method as the 'available': the code seems only
to use it in boolean tests.
- - Features may depend on (force inclusion of) other features.
- - Enabled features do their actual work by adding **kwargs to
the args passed directly to setup.py
- - Distributions created via an invocation to setup.py are not labeled
in any way to indicate any '--with-<featurename>' (or '--without')
passed to setup.py during their creation.
- - There is no way to enable / disable a feature when installing a
distribution via easy_install.
The particular use case which led me to investigate Features was easing
packaging of projects with optional C extensions, such that they could
be installable on Jython, IronPython, Windows, or GAE. It doesn't seem
possible to figure out whether a compiler actually exists: jython's
distutils lies and creates a compiler which raises exceptions, for instance.
Tres Seaver +1 540-429-0999 tseaver(a)palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
At 12:08 PM 7/2/2010 +0200, Tarek Ziadé wrote:
> From time to time this mailing list is getting very unpleasant to work
>in because some old disagreements,
>and because some people are starting to get really nasty.
>Here's a reminder of the current packaging situation, and a few rules
>I suggest, for the benefit of all
>1. Python <= 2.7 contains Distutils
>2. Distutils is frozen, and won't evolve anymore
>3. Setuptools is built on Distutils
>4. Distribute forks Setuptools for various reasons. If you disagree
>with this choice, there's no need to send a mail here, because this
> is done. You can send me a private mail, but don't send a mail
>here because things are always getting nasty afterwards.
> Make sure to read the archives first, to understand why it was done.
>5. Debian, Ubuntu and Fedora are using Distribute rather than
>Setuptools. If you find differences in the behavior, you can send
> a mail in this list, so we can fix Distribute. If you disagree
>with the distros choice, there's no need to send a mail here,
> because this is done. You can send *them* a mail, or tell them you
>disagree with this choice.
> Of course, the most effective behavior would be to work on having
>Distribute fixed if you find an issue, but that's up to you.
>6. Distutils2 is being built, and has its own mailing list now.
>Distutils2 will replace Distutils in Python 3.2 or 3.3.
> It' s built on the various PEPs that were accepted lately, and any
>help is welcome..
> The list is here:
>http://groups.google.fr/group/the-fellowship-of-the-packaging, and is
>7. New members of the lists will not know the situation, so they won't
>be able to follow these rules of course. But people that
> are hanging around here for years can apply them.
>Of course this is just a series of suggestion. You can disagree with
>all these rules if you want, but I think they need to be applied in
>this mailing-list for the benefit of all.
Isn't it interesting how these rules prohibit open disagreement or
criticism (or even discussion!) of distribute and related matters,
but *not* setuptools?
I mean, if I realized that as the maintainer of a package that people
were openly criticizing here, I could just post a list of rules to
the SIG and prohibit it, I might've done that five years
ago. ;-) (Nah, not really. But I'm certainly amused by how you've
suddenly become concerned with "tone" in the SIG as soon as you get
ONE person who's unhappy with distribute.)
On a separate note, I'm curious why discussion of Distutils2
development is not in a formal Python SIG, such as the Distutils-SIG.
I'm using stdeb in debian/sid and the control file it generates defaults
to build-depends on python-all-dev. What should I do to make it
(build-)depend on python-dev? I've tried the --xs-python-version option
but I got python-all-dev all the same.
Thanks in advance,