Distutils-SIG March 2009

distutils-sig@python.org

43 participants
67 discussions

Misleading exception thrown when attempting to install a missing .egg from a file:// url

by Fadhley Salim

Steps to re-create * Set up an environment as per my previous email but without the egg installed in site-packages. * Delete the egg from the egg_repository so that the file we expect to see is missing, but is still indicated in the html file which is used as the index of the egg repository directory. * Try to easy install the egg (as in previous example) and take note of the exception raised. My error is here: http://pastebin.com/m36b84d95 I'm guessing that we get a zipimporterror because the stream returned by the URL fetching fuction is obviously not zip data. However in this case might it be more appropriate to raise DistributionNotFound or some kind of special exception that more correctly describes this situation? Thanks, Sal This email does not create a legal relationship between any member of the Cr=E9dit 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=e9 des Etablissements de Cr=e9dit 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. This message and/or any attachments is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Crédit Agricole CIB. All rights reserved. Ce message et ses pièces jointes est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Crédit Agricole CIB ne peut pas être engagé par son contenu. Tous droits réservés.

12 years, 6 months

setuptools bug, inconsistent replacement of eggs when installing from file:// urls.

by Fadhley Salim

I think I've found a bug in the way that setuptools selects whether an egg specified by file:// url should be installed over an existing (identical) egg: To re-create the fault: * Install the egg of your choice. * make two local "egg repositories", one with a very long path (e.g. c:/a/) and one with a very long path * In each of the egg repositories place a copy of the egg you just installed, along with an HTML file containing a link to that egg... just it's filename. * Try to easy_install the egg with the options "-mv" and set "-f" to either one of the repositories When you select a short path for the repository you will notice that the egg in your site_packages folder is always replaced, you see something like this: "Removing d:\devtools\python24\lib\site-packages\calyon-1.0_r2009_03_12-py2.4-win3 2.egg" When you select a very long path for the repository you will not see this message, this is because easy_install leaves the egg unmodified. I've found out why this happens: The pkg_resources.Environment uses a hash-tuple to work out the order in which to consider packages to install. If you are trying to install two identical eggs, the 4th element of the tuple -len(self.location or '') becomes significant... longer URLs get preference to shorter URLs. That on it's own might not seem too bad, but consider the the 2nd value of the hash-tuple (precedence) is given an identical value of 3 both for a package which is already installed in pkg_resources and a package which can already be downloaded from a file:// link. I think a better default behaviour would be for it to give stuff that is already installed a higher precedence than stuff which could potentially be installed. Hope all of this makes sense! Sal This email does not create a legal relationship between any member of the Cr=E9dit 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=e9 des Etablissements de Cr=e9dit 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. This message and/or any attachments is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Crédit Agricole CIB. All rights reserved. Ce message et ses pièces jointes est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Crédit Agricole CIB ne peut pas être engagé par son contenu. Tous droits réservés.

12 years, 6 months

[issue64] Subversion 1.6 entries format 'unrecognized'

by Martijn Pieters

New submission from Martijn Pieters <mj(a)zopatista.com>: After upgrading to subversion 1.6, the dreaded unrecognized .svn/entries format pops up again. The entries format version number is 10, and if I add that to sdist.entries_finder, things appear to work just fine. Perhaps the test can be updated to parse the integer and use a >= 9 test on it, and just assume that future formats will continue to work until proven otherwise? ---------- messages: 253 nosy: mjpieters priority: bug status: unread title: Subversion 1.6 entries format 'unrecognized' _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue64> _______________________________________________

12 years, 6 months

Installing built C extensions

by David Cournapeau

Hi, Following one discussion on the python-dev ML, here is one of my recent frustration with distutils. I have a pure C library (pure meaning it does not use the python C API in any way) which I want to install so that other python packages can use it: from distutils.core import setup # How to install libfoo.a/foo.lib in say pkg_dir/lib ? setup(name='yo', libraries=[('foo', {'sources': ['foo.c']})]) I install headers in pkg_dir/include (for example site-packages/foo/include/foo.h), and I want to install foo lib in site-packages/foo/lib. I can't easily retrieve the library file in the build dir from setup.py, so I can't use install_data (and libraries are not data anyway), cheers, David

12 years, 6 months

PyPI mirroring and Changing the .egg-info PEPs

by Ian Bicking

Suggestions: Instead of http://pypi.python.org/mirrors how about http://mirrors.pypi.python.org (or pypimirrors.python.org, etc) -- then the mirror list can be hosted separately, and the likelihood of both the mirrors and the main PyPI server being down are much lower. Admittedly, this makes it harder for other indexes to provide their own mirrors, and the location is just entirely magic. But it seems like a useful magic. In the egg-info PEP: "They both add other files in the `EGG-INFO` or `.egg-info` directory, and create or modify `.pth` files. `pip` also creates one `.pth` file per installed package, which may lead to slow initialisation of Python." I don't believe this is the case. pip zip creates one .pth file for each zip file, but that's different. pip installs packages flat. Unless you use -e, which invokes setup.py develop, which I believe puts the path in easy-install.pth. Oh, you also use British English; "initialization"! I only notice that because my spell check is complaining about the quotation ;) As mentioned in another email, I think RECORD should hold relative paths (and PJE's "/" suggestion also of course seems reasonable). The paths should be relative to the .egg-info directory. "- get_egg_info(pkg_name) -> path or None Scans all site-packages directories and looks for all `pkg_name.egg-info` directories. Returns the directory path that contains a PKG-INFO that matches `pkg_name` for the `name` metadata. Notice that there should be at most one result. If more than one path matches the pkg_name, a DistutilsError is raised. If the directory is not found, returns None." Currently, if there are multiple paths that might be importable, whichever one is found first with sys.path is imported, and conflicts aren't really considered. raising DistutilsError seems like it changes this. " filename can be any value found in `distutils.sdist.EGG_INFO_FILES`." Is there any reason this should be restricted to those filenames? -- Ian Bicking | http://blog.ianbicking.org

12 years, 6 months

Packaging Survey first results + Summit schedule

by Tarek Ziadé

Hi, Sorry for the cross-post, but it seemed appropriate since packaging is being discussed in python-dev tonight, - Here are the first results for the packaging survey: http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/ - And tomorrow's Summit schedule for the packaging part : http://tarekziade.wordpress.com/2009/03/26/pycon-language-summit-is-tomorro… Please comment (in the appropriate list or in my blog) if you have something you would like to say or see addressed during the Summit and you are unable to be present. (I am already trying to summarize what has been said in python-dev today but I am not sure I'll be able to read everything before tomorrow) Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

12 years, 6 months

No Win exe for Python 2.6 on PyPI

by Peter Bobroff

Hi, I am relatively new to Python and recently had to install 2.6 on a coworker's computer. Not having a Windows 2.6 exe on the setuptools page of PyPI caused me considerable heartache and hassle. I eventually found a copy of setuptools-0.6c9.win32.exe which I had managed to build some months ago. I attach a copy in the hope it might shame someone with more experience into puting it or something better onto PyPI IMHO this is a major hurdle for a newcomer trying to use packages if the set up utility itself is missing. Ah! not allowed to attach .exe to this list. Deleted attachment and trying again. Regards, Peter Bobroff

12 years, 6 months

PEP 376 and the name .egg-info?

by Kevin Teague

I have some confusion over the name .egg-info. From what I understand, Eggs are a packaging format that contain metadata. But if you take a Distutils installed package and put a .egg-info file or directory beside it, that doesn't make the package an Egg, does it? To add to this confusion, I always associate the Egg format with the additional metadata fields provided by setuptools. So when I see .egg- info I always expect that the PKG-INFO will contain an 'install_requires' field, etc. It would be more understandable (to me) if this directory was named .pkg-info, .metadata, .install or something. But then I guess that's a somewhat disruptive change for small gains. An alternative to bridging the disconnect between the setuptools metadata fields and the distutils metadata fields would be to add the setuptools fields to distutils as standard package metadata. Adding those metadata fields hasn't been propsed yet as it's own PEP, has it? I guess that PEP would entail a little more work than just managing a set of fields since PyPI would also need to be updated to display those fields. But it would be really lovely to be able to see the 'install_requires' field when browsing PyPI - and click on links in that field to take you to those pakcages PyPI pages. And as an added bonus if the 'namespace_packages' field was clickable such that the link took you to a list of all packages which participated in that namespace, that'd be pretty sweet!

12 years, 6 months

[ANN] stdeb 0.3 released

by Andrew Straw

The latest version of stdeb, the automated Debian (and Ubuntu) package maker, is available for download. Stdeb takes your Python source (either a tarball or an a directory with a setup.py script) and turns it into a Debian source package. From there, it is trivial to turn it into a .deb file. This version adds support for Ubuntu Jaunty and python2.6 in Debian experimental by passing the "--install-layout=deb" option to "python setup.py install". Also in this release is a bugfix to the autofind-depends feature. The homepage: http://github.com/astraw/stdeb Download: http://pypi.python.org/pypi/stdeb/0.3

12 years, 7 months

binary executable in package

by Wolfgang Kerzendorf

Hello, I'm am distributing a package with binary executables which are compiled on installation. Everything works so far, except that when the binary executables are copied to the destination that they loose the executable flag. Here's the code: -------- #!/usr/bin/env python from distutils.core import setup from imp import find_module from os import system, path import os #This is a list of files to install, and where #(relative to the 'root' dir, where setup.py is) #You could be more specific. #find_module('pyraf') find_module('ephem') find_module('numpy') find_module('scipy') #find_module('SOAPpy') def makeAll(): curdir=os.getcwd() srcDir=os.path.join(os.path.dirname(os.path.abspath(__file__)), 'src/pywcs/extutil/src') os.chdir(srcDir) os.system('make clean') os.system('make') os.chdir(curdir) makeAll() setup(name = "pywcs", version = "0.91", description = "Collection of tools to use wcs information and fit new wcs to images", author = "Wolfgang Kerzendorf", author_email = "wkerzendorf(a)gmail.com", url = "http://www.mso.anu.edu.au/~wkerzend/", #Name the folder where your packages live: #(If you have other packages (dirs) or modules (py files) then #put them into the package directory - they will be found #recursively.) packages = ['pywcs'], #'package' package must contain files (see list above) #I called the package 'package' thus cleverly confusing the whole issue... #This dict maps the package name =to=> directories #It says, package *needs* these files. package_dir={'':'src'}, package_data = {'pywcs' : ["conf.d/sex.d/*","extutil/src/*","extutil/starmatch_new","extutil/finalmatch"] }, #'runner' is in the root. scripts = ["addwcs"] #long_description = """Really long text here.""" # #This next part it for the Cheese Shop, look a little down the page. #classifiers = [] ) ------ Thanks for any help Wolfgang

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