Distutils-SIG March 2009

distutils-sig@python.org

43 participants
67 discussions

by Lennart Regebro

Typical zc.buildout development installs zope.testing to run the tests. Typical zope.testing development uses zc.buildout. As you see, porting this to Python 3 gets well... tricky. ;) So the question (mostly to Jim, I guess) is if there is a way to easily run the tests for either zope.* or zc.buildout without using the zope testrunner et al? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64

12 years, 7 months

Using UNC paths as arguments to --find-links

by Fadhley Salim

I'd like to do something like this: http://python.pastebin.com/m283c0376 Basically, I'm invoking the easy_install command from a script. Where I specify a number ofn arguments to the --find-links option, some of which will be web-servers and at least one will be a local filesystem path, or possibly a network path un UNC format. It seems to work just fine when I do not provide a --find-links option (in this case it just picks up the defaults from distutils.cfg), when I use the option all I get is: Traceback (most recent call last): File "D:\workspace\pythonscripts_trunk\javapy_egg\Scripts\test_javapy.py", line 20, in ? result = pyproxy.requireEgg( eggspec , True, hosts ) File "d:\workspace\pythonscripts_trunk\javapy_egg\src\calyon\javapy\pyproxy.p y", line 141, in requireEgg pkg_resources.require(eggname) File "d:\python24\lib\site-packages\setuptools-0.6c9-py2.4.egg\pkg_resources. py", line 626, in require needed = self.resolve(parse_requirements(requirements)) File "d:\python24\lib\site-packages\setuptools-0.6c9-py2.4.egg\pkg_resources. py", line 524, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: myproject==trunk-99 Can somebody confirm the correct way to do this? For example do I use Windows or UNIX slashes? What character must be used to seperate multiple URLs? I'm using setuptools 0.6c9 on Windows32 Thansk This email does not create a legal relationship between any member of the Crédit Agricole group and the recipient or constitute investment advice. The content of this email should not be copied or disclosed (in whole or part) to any other person. It may contain information which is confidential, privileged or otherwise protected from disclosure. If you are not the intended recipient, you should notify us and delete it from your system. Emails may be monitored, are not secure and may be amended, destroyed or contain viruses and in communicating with us such conditions are accepted. Any content which does not relate to business matters is not endorsed by us. Calyon is authorised by the Comité des Etablissements de Crédit et des Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire in France and subject to limited regulation by the Financial Services Authority. Details about the extent of our regulation by the Financial Services Authority are available from us on request. Calyon is incorporated in France with limited liability and registered in England & Wales. Registration number: FC008194. Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.

12 years, 7 months

Distutils: distclass cmdclass

by Gerry Reno

Hi all, I've run into a situation where I need to have translations using L10nAppDistribution and we need to also have a special command class. What I'm finding is that I can have one or the other but not both. Does anyone know how to be able to use both distclass and cmdclass at the same time? Regards, Gerry Reno

12 years, 7 months

[issue63] setuptools & pyjamas

by Skip Montanaro

New submission from Skip Montanaro <skip(a)pobox.com>: This is more a reference submission than anything else. I submitted a patch for pyjamas to remove its installer's hard-coding of /usr/share. In my opinion the root for all installed files should be whatever --prefix is (whether explicit or implicit). The pyjamas ticket is <http://code.google.com/p/pyjamas/issues/detail?id=141>. Please have a look at it and add a comment if you so desire. Skip ---------- messages: 251 nosy: skip.montanaro priority: feature status: unread title: setuptools & pyjamas _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue63> _______________________________________________

12 years, 7 months

Releasing zc.buildout

by Tres Seaver

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm doing most of my development these days with Python 2.6, and would like to get a deprecation-warning-free version of zc.buildout released if possible for the projects which use buildout. I would be glad to make the release myself, if desired: just bless me with the PyPI stick and let me know. ;) Thanks! 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuQRR+gerLs4ltQ4RAg7cAJ9E6B99dOw1oWWK2lP4Dmk6YdO+BgCfdKAu ky5VUwFfP6cwqFziwwxoZBE= =5CBo -----END PGP SIGNATURE-----

12 years, 7 months

SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian)

by Manuel Amador (Rudd-O)

Hello, guys, I have fixed distutils (and setuptools remains working) with the attached patch. Now, RPMs will be built according to the Fedora Package Naming Guidelines: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non- Numeric_Version_in_Release which I understand to be the most useful reference in terms of naming pre- release packages. This should work correctly in at least: - Fedora - RHEL - SUSE I urge you patch your python 2.4s and 2.5s and 2.6s and push this update to distributions. I have done that myself at my own repository. Now we can enjoy one more reason to build RPMs (and eggs! ... according to my workbench at http://yum.rudd-o.com/SCRIPTS/ -- feel free to pick its brains) DIRECTLY from the cheese shop, especially if you're using pip. Oh, I also have pip at my repo (cd ../RPMS/noarch in my workbench). See attached patch. I will log bugs where it corresponds too. -- Manuel Amador (Rudd-O) <rudd-o(a)rudd-o.com> Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ Now playing, courtesy of Amarok: Aqua - Cartoon heroes Windows 95 is not a virus. Viruses actually do something.

12 years, 7 months

Adding a sub-command to the setup.py "build" and "develop" commands

by Brian Sutherland

Hi, I've just released a setuptools/distutils extension that makes the process of compiling translations (i.e. .po -> .mo files) quite automatic. http://pypi.python.org/pypi/van.potomo/ However, one major problem is that to modify the function of the setup.py "build" and "develop" commands one needs to do this in the setup.py: from setuptools import setup, find_packages from van.potomo import develop, build setup( name = "HelloWorld", cmdclass = {'build': build, 'develop': develop}, setup_requires = ["van.potomo"], version = "0.1", packages = find_packages(), ) Meaning that you have to manually install van.potomo before tools like buildout can run the setup.py to figure out the dependencies. Is there any way to make that more automatic, especially so that buildout can have a chance? >From my experience with Debian, there's a "Build Dependencies" field in the control file where one can specify such things. I'm kindof hoping there's a setuptools equivalent? I've searched for a while and most solutions involve monkey patching or too much code in the setup.py. -- Brian Sutherland

12 years, 7 months

Fixing parallel installs with easy_install / setuptools

by Garrett Cooper

Hello distutils folks, My group at Cisco uses easy_install / setuptools extensively for installing packages with our make system and there are 2 issues with using this with parallel make: 1. Duplicate dependencies cause corruption when installing the same package twice. 2. easy-install.pth is never updated according to the installed packages. Thus when we install 8+ packages and they all depend on python being installed 3. Cross-compilation is impossible (at least with what I've seen -- either that or the folks who hacked the sources before I got to it didn't understand that feeding in the correct variables would ensure that things could cross-compile). Then again many things Python don't cross-compile from what I've seen :(... the interpreter itself is a prime example =\. My goal is to fix these issues and contribute back the fixes, but I want to ensure that I use the best technical solution for the problems I mentioned. About problems 1 + 2: I'm short on time so I'm going to implement a simple locking mechanism around easy-install.pth. I also realize that .pth files are chosen because they are flat files and are included simply from within python with setup.py. Would it make more sense to use a backend database like pysqlite to store the package data though? That would require some reworking with setup.py, but considering that sqlite3 is _already_ included with 2.5+ and it's a public domain licensed piece of OSS software, would it make more sense to store packaging data with a stable system like SQLite, especially when it would make removal a trivial task? My knowledge of SQLite is limited, but I assume that it supports the same level of endian neutral code that other technologies like BDB do. Of course I'm going out on a huge limb in making that assumption, but the only document I found that blatantly disproves my claim straight out is http://groups.google.com/group/wview/browse_thread/thread/6fcc993dd548206c/… -- please correct me if I'm totally off-base. Also, please let me know whether or not you disagree with my proposal, and if there's a different method that could be employed which could maximize data integrity, assure ATOMicity, and guarantee that the data is endian neutral and thus portable to multiple platforms. About problem 3: Is the solution simple enough to solve using --build, --host, and/or --target, like configure, or does more gross work need to be done under the covers to make things all work? Thanks! -Garrett

12 years, 7 months

data in a source distribution?

by Arne Babenhauserheide

Hi, Is it possible to include data in a source distribution? I'd like to avoid eggs, since they don't integrate well with Gentoo packages, but I didn't find a way to include data in a source distribution (python setup.py sdist). Did I miss something? Best wishes, Arne -- -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln. -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

12 years, 7 months

Re: [Distutils] Setuptools should not depend on setuptools.

by P.J. Eby

At 06:20 PM 3/12/2009 +0100, Lennart Regebro wrote: >I don't have many assumptions. I just want the setuptools install and >tests to work as expected under both python2 and python3. And that >means that python3.0 setup.py install should work. And python3.0 >setup.py test would be nice too, although it's less important. In which case, either separate source distros are required, or 2to3 will need to be present, and the main setup.py will need to detect python3 and run 2to3 on itself, then execfile the setup script of the newly-generated, python3 version of the same package. Please note that even if you make setuptools "not depend on itself", all you are really doing is *moving* this problem to a different level. Whatever it is that it depends on, will still need to be duplicated for python2 and python3... and what's more, having a way worked out to do this will be of benefit to other packages besides setuptools, especially if setuptools provides some native support for the feature. (Like a standardized "setup.py" and "setup3.py" that delegate to the user's original 'setup2.py'.)

12 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG March 2009