Mailman 3 July 2010 - Distutils-SIG

Re: [Distutils] Python 2.7 is out and ez_setup.py does not work
by P.J. Eby 07 Jul '10

07 Jul '10

At 09:55 AM 7/7/2010 -0300, Hugo Lopes Tavares wrote: >Hi guys, >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.

1 0

What are non-active development eggs?
by Jason Baker 07 Jul '10

07 Jul '10

I've posted this question to Stackoverflow[1], but didn't get a response there so I thought I'd ask here. (This is simply a copy and paste of that question) 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 (/home/jason/src/interface_dev/elig) How exactly does a package go from active development to non-active development? [1] http://stackoverflow.com/questions/3187496/what-does-it-mean-when-a-package…

1 0

Python 2.7 is out and ez_setup.py does not work
by Hugo Lopes Tavares 07 Jul '10

07 Jul '10

Hi guys, 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?

2 1

trying to do a buildbot for zc.buildout on windows
by Adam GROSZER 07 Jul '10

07 Jul '10

Hello, I'm trying to make a buildbot for zc.buildout on various windows platforms. The problem is that bin/buildout acts weird when it's run by the buildbot process: http://winbot.zope.org/builders/zc_buildout_dev%20py_254_win32/builds/3/ste… OTOH, it's fine when running it manually (same credentials): C:\buildslave\zc_buildout_dev_py_254_win32\build>bin\buildout.exe C:\buildslave\zc_buildout_dev_py_254_win32\build>Upgraded: zc.buildout version 1.5.0dev; restarting. Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'. Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\zc.recipe.egg_' Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\z3c.recipe.scripts_' Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\.' Installing test. Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\test'. Installing oltest. Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\oltest'. Installing py. 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? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- 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

1 1

Bootstrap script for package management tool in Python 2.7 (Was: Re: [Python-Dev] At least one package management tool for 2.7)
by anatoly techtonik 07 Jul '10

07 Jul '10

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 before: "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python setup.py install" 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 http://pypi.python.org/pypi/setuptools/ 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 -- anatoly t. 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. > > Regards > Tarek > > -- > Tarek Ziadé | http://ziade.org >

11 29

Re: [Distutils] Packaging situation + mailing list rules
by P.J. Eby 06 Jul '10

06 Jul '10

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 decisions. 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?

5 7

setuptools' "Feature" feature
by Tres Seaver 03 Jul '10

03 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 distribution. - - 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. - -- =================================================================== 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 iEYEARECAAYFAkwuL/oACgkQ+gerLs4ltQ6gSACdHkbS6vic9+/ovRutN9c5Rue3 QBcAn176C4btyAU4j2AGlMsupviUxsTI =KAKk -----END PGP SIGNATURE-----

4 3

Follow-up on bug #143 / distribute
by Tarek Ziadé 03 Jul '10

03 Jul '10

Hello, I've fixed the issue #143 in distribute, along with some minor other points, and I will release 0.6.14 as soon as we check with Barry that it works fine upstream on Ubuntu/Debian. Other distros will follow. - Distribute issue: http://bitbucket.org/tarek/distribute/issue/142 - Ubuntu issue: https://bugs.edge.launchpad.net/ubuntu/+source/python-setuptools/+bug/601040 IOW, this removes the founded regression Distribute had with the latest setuptools release. In the meantime, if you have any other issue you would like to see addressed in this release, let me know. Tarek -- Tarek Ziadé | http://ziade.org

1 0

Re: [Distutils] Packaging situation + mailing list rules
by P.J. Eby 03 Jul '10

03 Jul '10

At 12:08 PM 7/2/2010 +0200, Tarek Ziadé wrote: >Hello, > > 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 >moderated. > >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.

7 17

stdeb- setting build-depends to python-dev
by lukshuntim＠gmail.com 03 Jul '10

03 Jul '10

Hi, 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, ST --

3 4