Mailman 3 July 2009 - Distutils-SIG

Re: [Distutils] Distutils History
by a.cavallo＠cavallinux.eu 22 Jul '09

22 Jul '09

On the "http://wiki.python.org/moin/Distutils/Friends", I've done something it might be interesting on the Distutils side already. It is my little pet project called pyvm (http://pyvm.sourcefoorge.net): it builds python (the trunk version) plus the related modules (in particular the distutils Tarek package). In theory there's no need to have a single stack (I do for my personal "pleasure") and modules can be build against any interpreters provided separately. Regards, Antonio On Wed 22/07/09 10:28, "Tarek Ziadé" ziade.tarek(a)gmail.com wrote: > On Wed, Jul 22, 2009 at 10:17 AM, anatoly techtonik<techtonik > @gmail.com> wrote: > Hello, > > > > I've added a chapter on Distutils history > to > http://wiki.python.org/moin/Distutils to > provide an overview why > current Distutils in not sufficient anymore and > needs refactoring. I > would like to ask for review to see if that > information is more > appropriate for Distutils/Critics > > > > That's great ! > > I'd rather see it at the top of the page since the next sections are > trying to fix the problems, > > Tarek > > > --anatoly t. > > > _______________________________________________ > Distutils-SIG maillist - > Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig >> > > > > -- > Tarek Ziadé | http://ziade.org _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig > >

1 0

[issue82] API for exposing the contents of requires.txt (and perhaps other metadata in .egg-info/)
by Sridhar Ratnakumar 21 Jul '09

21 Jul '09

New submission from Sridhar Ratnakumar <sridharr(a)activestate.com>: On Mon, 20 Jul 2009 17:20:44 -0700, P.J. Eby <pje(a)telecommunity.com> wrote: At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote: On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje(a)telecommunity.com> wrote: discovery.resources -- basically pkg_resources under a different name It may also be worth adding support for parsing the files under .egg-info - for instance, those 'extras' in requires.txt. See the 'requires()' method of Distribution objects: http://peak.telecommunity.com/DevCenter/PkgResources#distribution-methods I've already looked into that before (in pkg_resources.py) - unfortunately, this does not return all of requires.txt (as Python dict, that is), but only *what* you specify in the 'extras' argument (how am I supposed to know the / possible/ extras sections beforehand?). The closest I've come to is using `split_sections` and `_get_metadata` to construct the dict myself. But that is not the ideal way to provide/use an API. PJE: Ah, you didn't say that, you just said "parse". If you'll file a feature request, I'll replace _dep_map with a public attribute for accessing that information in a future release. In the meantime, you're quite safe using ._dep_map, since obviously I'm not going to change it out from under you. ---------- assignedto: pje messages: 330 nosy: pje, srid priority: wish status: chatting title: API for exposing the contents of requires.txt (and perhaps other metadata in .egg-info/) _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue82> _______________________________________________

1 0

Re: [Distutils] Including DLLs in binary distributions
by P.J. Eby 21 Jul '09

21 Jul '09

At 05:55 PM 7/20/2009 -0400, Jean-Paul Calderone wrote: >Hello all, > >I'm trying to figure out how to include some extra DLLs which are required >by an extension module I'm trying to package (pyOpenSSL). > > From what I can tell, the DLLs need to be in the same directory as the >extension modules themselves (the .pyd files). Does anyone know if this >is the best place for them? > >Based on my current understanding, I've used the data_files feature of >distutils to put the DLLs into site-packages/OpenSSL/. Use package_data instead; it should do the right thing with both distutils and setuptools. (It is available in the distutils as of Python 2.4; for 2.3 you'd have to use setuptools.)

2 3

Progress on the first distribute release
by Hanno Schlichting 21 Jul '09

21 Jul '09

Hi there. As promised I have gone through the setuptools tracker and tried to identify the easy and ready-to-apply patches. As a result I have applied the patches found in eight tickets [1] to the current distribute code. If you have another issue that is similarly uncontroversial and like it to be fixed, please report a new issue at http://bitbucket.org/tarek/distribute/issues/new. I've readied my Windows box to build the required binary distributions and installers for the 0.6 release. So hopefully there's just a few more documentation updates to make, before we can get this release out. Cheers, Hanno [1] In all its gory details these issues were: * Protected against failures in tarfile extraction. This closes http://bitbucket.org/tarek/distribute/issue/10. * Allow find_on_path on systems with tight permissions to fail gracefully. This closes http://bitbucket.org/tarek/distribute/issue/9. * Corrected inconsistency between documentation and code of add_entry. This closes http://bitbucket.org/tarek/distribute/issue/8. * Made api_tests.txt doctest compatible with Jython. This closes http://bitbucket.org/tarek/distribute/issue/7. * sandbox.py replaced builtin type file with builtin function open. This closes http://bitbucket.org/tarek/distribute/issue/6. * Immediately close all file handles. This closes http://bitbucket.org/tarek/distribute/issue/3. * Backported old distutils behaviour for add_defaults, to avoid a recursive loop when setuptools builds the file list. This closes http://bitbucket.org/tarek/distribute/issue/2. * Added compatibility with Subversion 1.6. This references http://bitbucket.org/tarek/distribute/issue/1.

6 11

Announcing the 'Distribute' project
by Tarek Ziadé 21 Jul '09

21 Jul '09

Hello, We have started a new project called 'Distribute'. It's a fork of setuptools and its initial purpose will be to tackle the most annoying bugs found in setuptools 0.6c9 version. A first version will be released as soon as possible (probably next monday) and a document will explain how to migrate from setuptools. This should be fairly easy. The next step of the project will be some cleanup and a split in two distinct distributions: - one that contains only pkg_resources - one with the setuptools package. The project is here : http://bitbucket.org/tarek/setuptoolsbranch We have an issue tracker there where you can add feature requests and bugs. Since its a DVCS repo, anyone is welcome to contribute patches. Regards Hanno, Chris, Tarek, and some other folks...

21 89

[Distribute] What versions should we support?
by Lennart Regebro 20 Jul '09

20 Jul '09

More specifically, Python 2.3 and/or 2.4? The current trunk (or whatever mercurial calls it) doesn't work with 2.4, because of a try/except/finally clause. That's fixable, but I ain't gonna fix it if we don't want to support 2.4 any more. I would claim that we should support 2.4. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

7 21

Including DLLs in binary distributions
by Jean-Paul Calderone 20 Jul '09

20 Jul '09

Hello all, I'm trying to figure out how to include some extra DLLs which are required by an extension module I'm trying to package (pyOpenSSL). >From what I can tell, the DLLs need to be in the same directory as the extension modules themselves (the .pyd files). Does anyone know if this is the best place for them? Based on my current understanding, I've used the data_files feature of distutils to put the DLLs into site-packages/OpenSSL/. This works fine for bdist_msi (and I hope bdist_exe, though I haven't checked that yet). However, bdist_egg has tripped me up. The path given in data_files is interpreted relative to the egg itself. This differs from the interpretation of those values by the other bdist_ commands. Here are the actual values I'm using: data_files = [('Lib\\site-packages\\OpenSSL', ['C:\\OpenSSL\\ssleay32.dll', 'C:\\OpenSSL\\libeay32.dll'])] How can I get these files into the right place for bdist_egg? Jean-Paul

1 0

Re: [Distutils] Fork mess
by P.J. Eby 20 Jul '09

20 Jul '09

At 01:36 PM 7/20/2009 +0200, Lennart Regebro wrote: >I feel that packaging discussions have a tendency to be severely lacking in >both mutual respect and ability to listen to others. This is not >limited to this list, and it seems to affect people who are normally >the friendliest ever. NOONE expects the Package Inquisition! Our chief weapon is surprise... surprise and fear... and a fanatical devotion to the Linux HFS... Too bad we don't get the nice red uniforms. ;-)

3 2

Distutils cookbook or how to specify a dependency?
by anatoly techtonik 20 Jul '09

20 Jul '09

Hello, I've noticed there is a Cookbook dedicated to distutils at http://wiki.python.org/moin/Distutils/Cookbook It looks a little deserted, so before asking to include my own specific problem into this Cookbook I would like to ask if developers are interested in using Cookbook approach as a supplement to a PEP. PEPs are good at presenting a solution, but bad at collecting primary information for testing the proposal. For example, most of us would like to see setuptools distributed with Python instead of downloading bootstrap script again and again. But there is already distutils module, so we should concentrate on enhancing it instead. But there is another but - distutils can not be enhanced, because... (well, why?) ... I can only suggest that distutils can not be enhanced, because it needs serious redesign, because it lacks too many features and there is a fear that redesign can break existing API and nobody can step in, because it is all the way too complex. But if there was a primary Cookbook page with listing of all the tasks you need distutils for and tasks you need setuptools for, it will be possible to port feature-by-feature. Having such page may save some time and present a tutorial and a reference for people who occasionally use setuptools to distribute their application without wasting too much time studying all the gory details of distutils/setuptools API. I've noticed that many developers find it hard to find an entrypoint into proper way to distribute their apps/modules, because of the lack of time. Don't you think that documentation for these people is something to be considered more seriously than PEP implementation or even the primary thing to start with? As for my specific problem - is there a way to specify dependency required to _install_ a package, so that easy_install would download that dependency prior to executing setup.py? --anatoly t.

1 0

Re: [Distutils] exclude a module, or can setuptools honor svn:ignore flag?
by P.J. Eby 20 Jul '09

20 Jul '09

At 03:45 PM 7/20/2009 +0200, Frank Hoffsümmer wrote: >Hello >I have a python project, 'myproject', that contains several >packages. one of those packages, 'myproject.settings', contains a >module 'myproject.settings.local' that is excluded from version >control via 'svn:ignore' property. >I would like setuptools to ignore this file when making a bdist or >bdist_egg target. >I have experimented with find_packages(exclude..) to no avail. >Ideally I was hoping that only files that are not ignored by svn >would be included. >Is there a way to achieve the exclusion of my module? I am on a >patched >(<http://bugs.python.org/setuptools/issue64>http://bugs.python.org/setuptools/issue64) >version of setuptools trunk, with subversion 1.6. >thanks for any insight you might have >-frank You might be able to use an exclusion rule in MANIFEST.in... but I think it would probably only affect an sdist. You'd then have to build from the sdist to get it to exclude. This is certainly something that should be fixed in setuptools.

1 0