Mailman 3 August 2009 - Distutils-SIG

distutils.cfg vs pydistutils.cfg
by Tarek Ziadé 13 Aug '09

13 Aug '09

Hello For http://bugs.python.org/issue6555, I was wondering if anyone recall why we have two different names (pydistutils.cfg vs distutils.cfg) As Zookoo pointed (and Google, if I search for "distutils.cfg pydistutils.cfg" :) ) it brings a lot of confusion, and I would like to deprecate pydistutils.cfg and have ".distutils.cfg" and "distutils.cfg" for the user-level file (unless someone finds a good reason it has to be different) Cheers Tarek -- Tarek Ziadé | http://ziade.org

3 7

Splitting distribute in several distributions
by Ian Bicking 12 Aug '09

12 Aug '09

On Tue, Aug 11, 2009 at 7:44 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > 2009/8/12 Sridhar Ratnakumar <SridharR(a)activestate.com>: > > I am glad that you have started thinking about the module split. > > > > 1) Why are the distributions named in CamelCase? Why not > > 'distribute.resources' instead of 'DistributeResources' (like, for > instance, > > zope.interface instead of ZopeInterface). > > Because the distribution name is not the packages names. > See for instance the Paste project : PasteScript, Paste, PasteDeploy. > Incidentally, when I named these Setuptools had a bug with certain characters in the package names, like ".". So there wasn't much of a choice at the time. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

1 0

bootstrapping virtualenv?
by Chris Withers 12 Aug '09

12 Aug '09

Hi All, Am I right in thinking the correct way to get a virtualenv without installing virtualenv into your site-packages is: - download a source distro of virtualenv - unpack it and copy virtualenv.py somewhere - use that virtualenv.py with whatever python you want to create your virtualenvs? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 3

virtualenv with distribute
by Ian Bicking 12 Aug '09

12 Aug '09

Philip Jenvey started a fork of virtualenv with Distribute support: http://bitbucket.org/pjenvey/virtualenv-distribute/ Right now there's some other higher priority things for virtualenv (i.e., straight up bug fixes and long requested features), and I want to get pip into environments (avoiding easy_install pip, which feels too ironic), and once pip is in then it would be necessary that Distribute be compatible with pip before this work could get merged. It would be ideal from my perspective if virtualenv could install Distribute in addition to Setuptools, not instead of Setuptools. This would be the least likely to cause backward compatibility issues for users, and people could transition at their own pace. I'm not really clear how compatible the two are. Also it would be advantageous to just have one line of development, so the newest virtualenv always installs the newest Distribute, and it's clear what that is (no different branches, no backward-compatible-breaking releases, etc). Of course, you will always be able to install Distribute into a virtualenv after creating it -- virtualenv's relationship to Setuptools is purely to bootstrap an environment to a useful state, and even if it installs pip you can always uninstall pip (or just mess with the environment so as to break pip, and then just not use pip). -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

1 0

[Distribute] Python 3 porting effort - plans proposal for 0.7/0.8
by Tarek Ziadé 11 Aug '09

11 Aug '09

Hello, (Following Ronald's mail about porting setuptools to Py3k (http://mail.python.org/pipermail/distutils-sig/2009-June/012108.html) and Lennart's effort for that too) Since setuptools doesn't exist yet under Python 3, I think we can simplify the "porting to Py 3k" problem by starting a python 3 only version for the Distribute project and flip our porting problems into the other way. Here's my proposal, after 0.6 is released : - Let's start a "0.8" branch right now, by removing all the bootstraping code and by splitting and renaming all elements right away. The setuptools package will be renamed in something else, the pkg_resources.py module and easy_install script too. Those will be three distinct distributions. To use them, people will have to change their import lines, and install_requires lines. - Let's then backport the 0.8 version into a 0.7 version, compatbile with Python 2.x and with the required bootstraping so it works in 2.x environments We might end up with a very ugly 0.7, but who cares this would boosts Python 3 adoption imho Opinions ? Cheers Tarek -- Tarek Ziadé | http://ziade.org

7 28

virtualenv with distribute
by Chris Withers 11 Aug '09

11 Aug '09

Hi Tarek, Any idea how I'd go about getting virtualenv to use distribute instead of setuptools? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 5

Distribute 0.7 development + 0.6 maint.
by Tarek Ziadé 11 Aug '09

11 Aug '09

Hi, I've created a branch for the 0.6 maintenance. and the default is now for 0.7. 0.6 ---- The plan is to continue the bugfixes for the 0.6.x series there. If you want to work on this branch, you need to switch to it like this : $ hg update -C 0.6-maintenance (see http://mercurial.selenic.com/wiki/Branch) Then you can work with this wiki page here: http://bitbucket.org/tarek/distribute/wiki/bug_listing Basically, all issues from the setuptools tracker can be mirrored and fixed on our side, as long as it's a real bug fix (no API/behavior change) Patches are welcome ! 0.7 ---- The plan is to start the refactoring: - py3k support - split the code in several distributions - think about new features / behaviors, we need Help is welcome ! (of course we need to backport bugfixes from 0.6 to 0.7) Cheers Tarek -- Tarek Ziadé | http://ziade.org

2 1

Distribute and zc.buildout + bootstraping file names + release/branches roadmap
by Tarek Ziadé 08 Aug '09

08 Aug '09

Hi, I am working on the last bits to be able to release 0.6 1/ Distribute and zc.buildout I started to work on the last bootstraping problem we have : make sure zc.buildout users can use it. I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that is a patched version of zc.buildout's bootstrap.py. This version makes sure Distribute is installed and activated in a buildout environment. It's also in the repo, in the buildout directory. Again, this requires a lot of real-world testing before we can ship 0.6. I've started to test various combinations on my side, but as I did for the previous bootstraping script, I wouldn't mind having some feedback of various people on this. If you use zc.buildout, you can try it by replacing the bootstrap.py file that comes with your buildout with the one I work on, then a/ add "distribute" to the required eggs in your buildout cfg file b/ run or re-run the bootstrap: $ wget http://nightly.ziade.org/bootstrap.py $ python bootstrap.py If it worked, your buildout should build and work just fine, and the scripts located in bin/ should have their sys.path augmented with the distribute egg. Last, the setuptools egg is faked and you wil notice that it's empty. This has to be done so zc.buildout and any software out there that has a hardcoded dependency on setuptools thinks it's present. This is reversible, by running the original bootstrap and removing the egg dependency added in the cfg file. Please let me know if you try and get in any trouble. I was able to run a plone buildout on my side with no problems. 2/ bootstraping file names To avoid any confusion, I've changed distribute's bootstrap file name. So we will have: - ez_setup.py = setuptools bootstrap file - bootstraping.py = distribute bootstrap file - bootstrap.py = zc.buildout bootstrap file If you think "bootstraping" is a silly name, or have a better proposition, please let me know. 3/ release/branches roadmap I'll probably release 0.6 before the end of this week and I expect pushing a 0.6.1 one if we find big issues with the bootstraping we didn't see before, when the release goes live. As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance and we will be able to work on 0.7 on the default branch, including the Python 3 work. Other Py3k remaning branches will be removed/stripped. I think this is a simpler approach. The 0.7 release will get ridd of the bootstraps script and create several distributions, so a massive refactoring is expected. I don't know if this will make it harder for py3k work, Lennart, Ronald ? Cheers Tarek -- Tarek Ziadé | http://ziade.org

8 39

Bizarre behaviour with --prefix
by Josh Holland 08 Aug '09

08 Aug '09

I am encountering some interesting behaviour with python setup.py install. $ python setup.py -n install running install running build running build_py running build_ext building 'suvatext' extension creating build/temp.linux-i686-2.6 creating build/temp.linux-i686-2.6/suvatlib gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c suvatlib/suvatext.c -o build/temp.linux-i686-2.6/suvatlib/suvatext.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-i686-2.6/suvatlib/suvatext.o -o build/lib.linux-i686-2.6/suvatext.so running build_scripts changing mode of build/scripts-2.6/suvat running install_lib copying build/lib.linux-i686-2.6/suvatext.so -> /usr/local/lib/python2.6/dist-packages copying build/lib.linux-i686-2.6/suvatlib/__init__.py -> /usr/local/lib/python2.6/dist-packages/suvatlib copying build/lib.linux-i686-2.6/suvatlib/suvatwin.py -> /usr/local/lib/python2.6/dist-packages/suvatlib copying build/lib.linux-i686-2.6/suvatlib/suvatcalc.py -> /usr/local/lib/python2.6/dist-packages/suvatlib error: file '/usr/local/lib/python2.6/dist-packages/suvatlib/__init__.py' does not exist $ python setup.py -n install --prefix=/usr running install running build running build_py running build_ext building 'suvatext' extension creating build/temp.linux-i686-2.6 creating build/temp.linux-i686-2.6/suvatlib gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c suvatlib/suvatext.c -o build/temp.linux-i686-2.6/suvatlib/suvatext.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-i686-2.6/suvatlib/suvatext.o -o build/lib.linux-i686-2.6/suvatext.so running build_scripts changing mode of build/scripts-2.6/suvat running install_lib copying build/lib.linux-i686-2.6/suvatext.so -> /usr/lib/python2.6/site-packages copying build/lib.linux-i686-2.6/suvatlib/__init__.py -> /usr/lib/python2.6/site-packages/suvatlib copying build/lib.linux-i686-2.6/suvatlib/suvatwin.py -> /usr/lib/python2.6/site-packages/suvatlib copying build/lib.linux-i686-2.6/suvatlib/suvatcalc.py -> /usr/lib/python2.6/site-packages/suvatlib error: file '/usr/lib/python2.6/site-packages/suvatlib/__init__.py' does not exist It seems that, without the --prefix option, the package suvatlib is being installed into dist-packages, while with --prefix=/usr, the package is going into site-packages. This is with python 2.6.2 on Ubuntu Karmic. -- Josh Holland <jrh(a)joshh.co.uk> (key F6067C12) http://joshh.co.uk dutchie on irc.freenode.net http://twitter.com/jshholland http://identi.ca/jshholland

2 1

Re: [Distutils] Distribute and zc.buildout + bootstraping file names + release/branches roadmap
by P.J. Eby 05 Aug '09

05 Aug '09

At 08:14 AM 8/5/2009 -0400, Jim Fulton wrote: >It would be great if we could come up with a >much smaller install library that multiple packages could share. I've previously proposed to split out installation stuff (plus pkg_resources) to such a library, leaving just the setup.py/easy_install aspects in setuptools proper. This is currently still a vaporware proposal, but I've at least done a bit more specific code sketching since then. The original concept notes can be found here: http://mail.python.org/pipermail/distutils-sig/2009-July/012685.html I don't know if this is exactly what you had in mind, but I expect it's at least somewhat similar; your previous request for "easy_install as a set of independent functions" was not forgotten. ;-)

1 0