Mailman 3 October 2008 - Distutils-SIG

Re: [Distutils] Potential issue with multiple easy_install instances and single easy_install.pth
by Phillip J. Eby Oct. 19, 2008

Oct. 19, 2008

At 07:14 PM 10/18/2008 -0700, Garrett Cooper (garrcoop) wrote: >Hi Python folks, > As part of a build system I work with, my group installs >multiple Python packages via source using easy_install. One such issue >I've seen before in the past is that when using multiple easy_install >instances (via multiple make jobs), the last instance that opened up >easy_install.pth records its changes; the file should contain entries >for all packages installed by easy_install. easy_install doesn't support simultaneous parallel installations to the same target directory, and there are no plans at the moment to add that support. Note, however, that if you use the -m (--multi-version) option, then easy_install will not save the .pth file unless there was already a default version of the target package present. However, if you begin by deleting the .pth file altogether, then using -m will avoid creating or updating it. Of course, the downside of -m is that you will not be able to access the installed packages except via setuptools-built scripts or by using explicit require() calls.

2 1

Potential issue with multiple easy_install instances and single easy_install.pth
by Garrett Cooper (garrcoop) Oct. 19, 2008

Oct. 19, 2008

Hi Python folks, As part of a build system I work with, my group installs multiple Python packages via source using easy_install. One such issue I've seen before in the past is that when using multiple easy_install instances (via multiple make jobs), the last instance that opened up easy_install.pth records its changes; the file should contain entries for all packages installed by easy_install. I was wondering if this was a known issue / caveat and/or whether or not anyone was possibly working on rectifying the problem. One workaround to this issue I could think of is possibly using a single .pth file per egg, as Python by default opens up all .pth files at startup in site-packages using a *.pth glob, but the only issue is open file descriptors and wasted cluster space with a number of small files... Either that or easy_install could (more properly) use a database backend for storing all package registries, which would not only simplify adding the .egg entries, but also simplify deleting .egg entries as well (a feature missing from easy_install and I believe from setup.py as well). Thanks! -Garrett

1 0

Classifiers for Python versions
by "Martin v. Löwis" Oct. 18, 2008

Oct. 18, 2008

As suggested in issue 2169549, I have now added a number of trove classifiers to PyPI to denote support for certain Python versions, namely Programming Language :: Python :: 2 Programming Language :: Python :: 2.3 Programming Language :: Python :: 2.4 Programming Language :: Python :: 2.5 Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3 Programming Language :: Python :: 3.0 Programming Language :: Python :: 3.1 With these, packages can indicate that they support 2.x (but not 3.x), or that they have been tested/written for specific Python releases. As a side effect, packages can now expressly state that they support Python 3000. Regards, Martin

2 1

Proxy server with easy_install (Python noob)
by James Mansion Oct. 18, 2008

Oct. 18, 2008

Bit of a Python noob I'm afraid. I'd like to install Sphinx with easy_install, but its timing out. I'm running XP sp3. This is the usual symptom of trying to use software that hasn't noticed that it needs to use a proxy server to get out of my network. Searches seem to come up with implementations of a proxy server in Pythn (and installation thereof) rather than a way to tell easy_install or installutils etc where my squid server is. Can anyone help? Thanks in advance James

2 1

[patch] executable Scripts on windows
by anatoly techtonik Oct. 17, 2008

Oct. 17, 2008

Hello, I would like to discuss a patch that adds executable .bat files for scripts installed with distutils. As a windows user with several Python versions installed I often create shortcuts for Python applications that were installed using distutils. But I also have to navigate to Scripts/ directory and mess with script files. Common problems: 1. python script doesn't have .py extension 2. script is actually a shell script 3. script is executed with wrong Python version The first problem is clear. Files without extension are not executable on windows. If distutils makes scripts executable on posix, why shouldn't it do the same on windows? The second problem should be addressed to package maintainer in the first place. The third one is also quite common - distutils fixes scripts and inserts correct Python path in shebang even on windows platform, but it makes little sense, because the script is executed with the only interpreter that was associated with .py extensions. To solve problems 1 and 3 I added patch that adds .bat file to execute the script with correct python version. As a positive side effect - the application can be executed through "Run" menu. The patch is posted into http://bugs.python.org/issue4015 and I would like to know your opinion about it. -- --anatoly t.

1 0

Re: [Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification
by Phillip J. Eby Oct. 17, 2008

Oct. 17, 2008

At 10:04 AM 10/7/2008 +0100, Paul Moore wrote: >2008/10/7 Phillip J. Eby <pje(a)telecommunity.com>: > > In the case of BUILDS, I propose to do the same: define a standard whose > > cost/benefit ratios are ideally balanced for each participant. This does > > not, by the way, mean that everybody ends up with the same cost/benefit > > ratio; it simply means that the cost/benefit ratios are best for those > > people whose participation is most required for the standard to be widely > > adopted. > > > > You can see that this is also what I did in the design of easy_install and > > setuptools, except that in that effort I only considered developers and > > users, not system packagers. > >I'd argue (you may differ) that the most significant area where you >missed the mark on user benefits with easy_install and setuptools is >the lack of easy *uninstall* and easy *list* options. Well, I'd certainly agree that those features are desirable. But I didn't "miss the mark", in that those features were not part of my mark. ;-) The goal was to get widespread adoption by developers, and thus the primary target audience was developers. Any features that attracted users were there only insofar as the benefit to users would specifically drive adoption by developers. And that means that features that only matter *after* you have things installed (i.e., easy uninstall and list) were of relatively little importance in the initial feature set. It was only necessary to provide the *possibility* of uninstall and list features, and then allow others to scratch the resulting itches. Now, for BUILDS, the situation is different. Just as setuptools' competitor was distutils, BUILDS' competitor is setuptools. So, BUILDS has to offer developers a switching benefit. And, unlike the situation before, now developers are much more likely to have a lot of packages they'd like to list or uninstall, so such features have considerably more value now, than they did then, which makes them worth putting some effort into. Also, since that switching benefit is largely going to come from having better management tools, the management tools need to be easy to build (so that people will build them). However, since system packagers are experiencing pain right now wrt Python packages, there is at least some benefit to their participating in the process. Back when setuptools was developed, people from the distros weren't hanging out here in the distutils-sig... or at least, they never answered any of my calls for interested parties. > Most of the >issues I hear from users about setuptools (filtered by my prejudices, >admittedly) is that there's no management options (which brings in the >system packagers, and their concerns). > >Can I suggest that this be included somehow in the new spec, so that >metadata is available to make wtiting uninstallers and listers as easy >as writing installers? Since the single most important part of BUILDS (and the part that should be done first) is an installation manifest for packaging tools to know what files are of what kind and where, it should be easy for uninstallers to work. Regarding listers, there are already a number of them available in the Cheeseshop, and if you're working with Python 2.5+ (and not using an older distro that deletes .egg-info files), they should also work with distutils-installed packages. The idea behind the installation manifest and metadata (the "IL" and "DS" of BUILDS) is that it should be possible for anyone to write their own management tools for specific scenarios, and not have to rely on a bunch of implementation-specific and not-very-well-documented stuff. (It should also be possible, given the "IL" part, to make a distutils and/or setuptools command that generates this data from a sufficiently well-behaved setup.py.)

8 8

Separate source and build folders
by Michael Jones Oct. 16, 2008

Oct. 16, 2008

Hi, I've got a directory structure that looks like: ./setup.py ./src ./src/dn where dn is a package containing my code. My setup.py looks like this: ------- from setuptools import setup, find_packages setup( name = "dnpkg", version = "0.1.7", packages = ['dn', 'dn.pkg', 'dn.pkg.interface'], package_dir = { "": "src"}, namespace_packages = ['dn'], install_requires = ['SQLAlchemy>=0.4.2p3'], entry_points = { 'console_scripts': [ 'dnpkg.test = dn.pkg.interface.commandline:main', 'dnpkg.testweb = dn.pkg.interface.web:cgi', ] }, package_data = { 'dn.pkg' : [ 'templates/user/*.mako', 'templates/show/*.mako', 'templates/project/*.mako', 'templates/*.mako' ], } ) ------- As indicated I have two console scripts. This setup works fine the console scripts are installed as desired. However I would like to have a separate build directory so the layout matches my other (non-python) projects. So I created a build directory, put my setup.py in there and so I have: ./build ./build/setup.py ./src ./src/dn And I changed the package_dir line in setup.py to "../src" instead of "src". Now it appears ok, running "python2.5 setup.py bdist_egg" in the build directory does much the same as in the old directory structure. But when I do an install, I no longer get the lines: Installing dnpkg.test script to <path> Installing dnpkg.testweb script to <path> and the scripts don't appear where they should. What am I missing? I've been reading the docs but can't figure out where I'm going wrong. Any help would be much appreciated, Michael

1 0

developing a package and two packages it depends on
by Chris Withers Oct. 15, 2008

Oct. 15, 2008

Hi All, I have a package that has a setup.py containing the following: setup( name='xlutils', ... install_requires=[ 'xlrd', 'xlwt', ], ) I'm using buildout to setup and development and testing environment for this project so I have a buildout.cfg containing the following: [buildout] develop = . parts = test py [py] recipe = zc.recipe.egg eggs = xlutils interpreter = py [test] recipe = zc.recipe.testrunner eggs = xlutils How can I get the above to use a checkout of xlrd and xlwt's trunk? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 3

Re: [Distutils] [Catalog-sig] distribute D.C. sprint tasks
by "Martin v. Löwis" Oct. 14, 2008

Oct. 14, 2008

> If you are going to formalize such procedures, it may also be worth > thinking about the case of someone uploading code that they do not have > rights to. It's not very likely, but the response often must be swift, > at least in some jurisdictions. The potential for mirrors, and thus the > need for coordinated action, makes it even more important to formalize a > procedure, IMO. The procedure for such a case is fairly obvious: when the true copyright holder requests removal (e.g. through the bug tracker, or by email to the PSF, which appears as the responsible entity of the website), the files would be deleted immediately, and the uploader would be requested to clarify. Regards, Martin

1 0

Setuptools Windows binary for Python 2.6
by Paul Moore Oct. 13, 2008

Oct. 13, 2008

I see that there's a Win32 egg for setuptools for Python 2.6, but no bdist_wininst style installer. Will a bdist_wininst installer be provided? When is it likely to be available? Paul.

1 0