Mailman 3 January 2008 - Distutils-SIG

Uploading an egg behind a proxy
by David Cournapeau 26 Jan '08

26 Jan '08

Hi, I would like to upload an egg to the cheeseshop, but I have a problem because my network is behind a proxy. My configuration is unusual in the sense that my network has no DNS server, and everything is done through the proxy: proxy has to be used to access an url: Submitting dist/numscons-0.3.1-py2.5.egg to http://www.python.org/pypi (-2, 'Name or service not known') I know for sure I can access pypi, and that this is a proxy related problem (other python projects relying on urllib2 had similar problems, e.g. bzr). cheers, David

3 5

setuptools on jython
by Philip Jenvey 24 Jan '08

24 Jan '08

Jython trunk has made a lot of progress on setuptools support. The gory details are here: http://wiki.python.org/jython/SetuptoolsOnJython The final few issues require some changes to setuptools itself: o usage of os.chmod. most uses are actually wrapped in an os.name == 'posix', or except AttributeError checks, but one was missed (Jython lacks os.chmod) o a unit test assumed CPython dict ordering I've attached a patch against the 0.6 branch for both of these issues. Though there's one more issue that'll be more difficult to deal with: setuptools uses marshal.load to read variables (via co_names and co_consts) from a module's bytecode (pyc/o) without importing it. Jython and IronPython don't compile to .pyc, nor do their code objects support co_names and co_consts, so this isn't portable. marshal.load is used in a couple places: o setuptools.depends.extract_constant, which is only used in setuptools by Require.get_version(). I don't know when this is used or what it's used for o to find un-zip_safe variables/calls when a distribution doesn't specify zip_safetyness. Probably the easiest way to deal with this is to just fallback to zip_safe=False on these platforms -- Philip Jenvey

5 9

multiple servers handling in .pypirc
by Tarek Ziadé 22 Jan '08

22 Jan '08

Hello, like discussed in catalog-sig, and explained here: http://wiki.python.org/moin/EnhancedPyPI I am submitting a patch for distutils so .pypirc can handle several servers: http://bugs.python.org/issue1858 It allows having a .pypirc that handles several servers, using the -r option together with several couples of username/password. I am not quite sure about the acceptation process for such a patch, since it was built through a discussion in catalog-sig, so I am presenting it here for review, feedback, etc. Regards Tarek -- View this message in context: http://www.nabble.com/multiple-servers-handling-in-.pypirc-tp14917917p14917… Sent from the Python - distutils-sig mailing list archive at Nabble.com.

2 4

wish: a setuptools plugin that does freshmeat-submit
by zooko 21 Jan '08

21 Jan '08

Folks: Freshmeat.net now offers an XML-RPC API to submit project metadata and release announcements. There is a client implementation by ESR in Python. http://freshmeat.net/articles/view/1048/ My wish is that I could install a setuptools plugin, and subsequently do "./setup.py upload freshmeat-submit" to announce new versions to both PyPI and freshmeat.net. Regards, Zooko

2 1

Re: [Distutils] pypi and easy_install
by Phillip J. Eby 21 Jan '08

21 Jan '08

At 08:10 PM 1/19/2008 +0100, Giampaolo Rodola' wrote: >Just another thing. >I was wondering what do you think would be better to do as default. >Using Python modules as default and spawn() as fall back or doing >the contrary? >Maybe using spawn() as default would be better since original >utilities should be faster than python modules. I suppose that's a possibility, although the tarfile module doing the compression might be faster than separate tar and compress steps. The other argument for using spawn() first would be that it's the least invasive and most backward-compatible change.

2 4

Experience of setuptools' cache design
by Viktor Fougstedt 20 Jan '08

20 Jan '08

Hello. Being nothing but an innocent bystander, I have not thuroughly searched the archives of this list, and might be writing about something that is "old news" since long ago. If so, I apologize. This is a small story about what I, being an end user that did not know what "setuptools" was, experienced when I installed the latest MySQLdb module (and I am aware that there might very well be issues with how it was installed). My hope is that this is useful to the developers of setuptools in determining if they meet the design criteria they have set up. A colleague of mine installed the latest MySQLdb module, which uses eggs and setuptools. We use Python and MySQL heavily on our mailserver. In that environment, user names and home directories do not always match, and indeed most users running the programs are system users and do not have home directories at all. This showed to be a problem with the setuptools-based MySQLdb module. The reason is the .python-eggs directory. Our configuration daemon runs as a system user "graald", a user without a home directory (that user does not have a vaild shell either). After updating MySQLdb to the setuptools-based version, the Python server code no longer started, because setuptools tried to write to the .python-eggs directory in the user's $HOME. And $HOME is not a valid directory (or, often, the home directory of the person starting the script rather than the account it runs as). Ok, so we can set the PYTHON_EGG_CACHE environment variable, which solves the problem (but in an unclean way). Then comes the Python script that runs as "virtmail" and tries to connect to MySQL, "virtmail" being another user without a home directory. And of course it does not start, and cannot have the same PYTHON_EGG_CACHE directory, since both these users cannot write to the same directory. And, not having a home directory, the "virtmail" user does not have a .bashrc or similar where we can set that user's own cache directory. We cannot set PYTHON _EGG_CACHE in the script itself either, as we cannot know what to set it to. Because if two different system users run the same script, they need different cache directories. Uh-oh. We need to implement code to direct the cache directory depending on the user that's running. And when I tried to run a script under my own user, with a proper home directory, nothing worked as expected either. The reason? I have previously run a Python script as root (but without changing my $HOME at that time). So now I have a .python-eggs in my own home directory owned by root:root. My thoughts (perhaps useful, perhaps not): * Primarly, I think it is unfortunate that an "import foo" starts creating files in the file system - it is not what I personally expect from doing an "import"! * On our user system, with some 20.000 active users, there will be up to 20.000 copies of a .python-eggs directory if someone installs a program that uses a Python Egg (but does not have access to site- packages or does not know how to detect what eggs are used and how to install them there). * I, personally, think it would be better if I explicitly have to _request_ a per-user cache directory being made, rather than needing to implement solutions to _prevent_ that from happening. * If the default is to remain to create files on "import", I would like error checking and fall backs. If the cache directory cannot be created in $HOME, I would like the code to create it somewhere else (or not at all) instead of giving me an exception. As end user I did not request the cache-directory to be made, and therefore do not want to be given an exception caused by it not being created. Especially as I do not know what to do with such an exception. Perhaps creating it in /tmp/python-eggs-$USERNAME, for example. Thanks for listening. /Viktor

6 15

Re: [Distutils] pypi and easy_install
by Phillip J. Eby 19 Jan '08

19 Jan '08

At 04:44 AM 1/19/2008 +0100, Giampaolo Rodola' wrote: >Ok, I tried to implement this and it is seems I made it. >The change permit to use the distutils "--formats=tar,gztar,bztar" >option without need of having tar/gzip/bzip2 utilities installed on >the system. >Don't know if distutils test suite includes tests for the part of code >I modified but Lib/test/test_distutils.py run successfully on Python >2.5.1. > >The only compression format currently left out is ztar. >I may be wrong but I haven't seen modules able to work with that >format in the Python stdlib. > >I'll wait for your review. >Tell me if you want me to open a ticket on the Python bug tracker to >let also other users review the patch, modify something or throw the >whole thing away. :-) That would probably be a good idea. In the meantime, my only comment is that for consistency with make_zipfile, the code should work even if gzip, tarfile, or bz2 aren't importable. That is, falling back to the old spawn-based methods if the relevant library or libraries are not available. The comment at the top, after all, says "This module should be kept compatible with Python 2.1," and the tarfile and bz2 modules weren't added until 2.3. (I'm not sure when gzip was added.)

2 4

Package in both setup_requires and install_requires will not be installed
by Michael Hoffman 19 Jan '08

19 Jan '08

Joshua Boverhof previously reported this in <http://mail.python.org/pipermail/distutils-sig/2007-March/007436.html>. If you specify a package in setup_requires it will be built in the current directory. But even if it is in install_requires as well, it won't be installed because the requirement is already satisfied at setup time by the package in the build directory. Is there a workaround for this?

2 7

Re: [Distutils] pypi and easy_install
by Phillip J. Eby 18 Jan '08

18 Jan '08

At 06:39 PM 1/16/2008 +0100, Giampaolo Rodola' wrote: >2008/1/16, Phillip J. Eby <pje(a)telecommunity.com>: > > At 03:48 PM 1/16/2008 +0100, Giampaolo Rodola' wrote: > > > > > Unfortunately the distutils.archive_util module was written before > > > > > tarfile was available. > > > > > >Are there chances to see this implemented? > > > > Are you volunteering? :) If so, then perhaps you can get a patch in > > for Python 2.6. > >Uhm... why not? :-) >If someone could give me some pointers on nailing down the issue I >could give it a try (note: never seen distutils internals before). See the distutils.archive_util module - the disutils uses that for all its archive creation. >My only concern is that it's not rare that patches provided by users >are often ignored and they remains stagnant on the Python bug tracker. >I just wouldn't spend time on that for nothing. Well, I can review the patch and commit it, if I like it. :)

2 2

Patch for minor easy_install problem
by Toshio Kuratomi 18 Jan '08

18 Jan '08

It looks like this fix to easy_isntall: ''' 0.6c5 * Fixed .dll files on Cygwin not having executable permisions when an egg is installed unzipped. ''' introduced a minor bug. From 0.6c5 on, installing an egg unzipped makes all the files executable. Attaching a patch that only makes .dll's executable. -Toshio

2 1