Distutils-SIG December 2008

distutils-sig@python.org

31 participants
44 discussions

by devel＠jonasmelian.com

When I use the next command in my home system: $ python setup.py develop Pyrex compiles the '.pyx' file without any problem. But after of uploading it to Pypi, and when is installed via 'easy_install' it doesn't builds any more. (I had to upload the '.c' file compiled on my system) You can see here how has been configured: http://www.bitbucket.org/ares/bcryptwrap/src/tip/setup.py and here where I had to add any files: http://www.bitbucket.org/ares/bcryptwrap/src/tip/MANIFEST.in Note that in the last verion in Pypi I've only one of the next sentences but I had both ones in anterior revisions. setup_requires='Pyrex', install_requires='Pyrex', It download and install Pyrex before of my package, but Pyrex doesn't compile the file.

12 years, 4 months

easy_install adds bad interpreter shebang to installed scripts

by Felix Schwarz

Hi *, I'm using Python 2.5 on Fedora Linux 9. If the path to the interpreter contains spaces and I install some eggs with scripts using easy_install, all installed scripts will have a non-functional shebang line like this: #!"/home/foo bar/bin/python" On Linux (and I think this is true for all Un*x flavors) you can not quote the shebang path and there is no way around this [1]. To make it more clear where the problem is I attached some kind of 'patch'. My idea was that quoting shebang paths seem to work on Windows (at least this was my impression from reading the changelogs) but on Linux there is no way to generate a working shebang line with an absolute path. Therefore it would help me if /usr/bin/env is queried. Probably this will break for some people but currently the behavior is broken for everyone. With virtualenv you have to call activate (instead of calling the installed script directly) but then everything will work fine. Do you consider this a kind of bug you might be inclined to fix? fs [1] http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/861a98e53b…

12 years, 4 months

Error downloading pythonutils from pypi: Can't process plain .py files

by Jason R. Coombs

Downloading pythonutils from pypi fails even though it is downloading a perfectly good .zip source file. > easy_install pythonutils==0.3.0 Searching for pythonutils==0.3.0 Reading http://pypi.python.org/simple/pythonutils/ Couldn't find index page for 'pythonutils' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Reading http://pypi.python.org/simple/Pythonutils/ Reading http://www.voidspace.org.uk/python/modules.shtml#pythonutils Reading http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=pythonutils-0. 2.3.zip Reading http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=pythonutils-0. 2.5.zip Reading http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=pythonutils-0. 3.0.zip No local packages or download links found for pythonutils==0.3.0 error: Could not find suitable distribution for Requirement.parse('pythonutils==0.3.0') If I download the .zip file manually and easy_install the zip file, the install goes great. I think the problem is related to the .py name appearing in the filename. > easy_install http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=pythonutils-0. 3.0.zip Downloading http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=pythonutils-0. 3.0.zip error: Can't process plain .py files without an '#egg=name-version' suffix to enable automatic setup script generation. I'm guessing that whatever easy_install uses for downloading the file ends up naming it downman.py (or something similar). I checked the headers on the response from voidspace, and I see voidspace is in fact supplying the content-disposition header: content-disposition: attachment; filename= "pythonutils-0.3.0.zip" So it appears that whatever downloader easy_install is using isn't honoring the content-disposition header. or the check for python-ness is otherwise getting a false positive. This problem was observed in Windows Vista 64-bit with Python 2.5.2 32-bit and setuptools 0.6c9. Should I post a bug in bugtracker on this issue? Regards, Jason

12 years, 4 months

Unsetting something from distutils.cfg

by Ian Bicking

Is there any way, when you have a setting in distutils.cfg, to unset that value? For instance, if you've set: [install] prefix = something Is there a way to get distutils to ignore this setting? Setting it to the empty string doesn't seem to do it, and I don't know of any other way. -- Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org

12 years, 4 months

"Stable" versions

by Ian Bicking

I've received a request that pip be able to be restricted to "stable" versions. It was suggested some kind of --alpha-ok or --beta-ok option, but this seems crude. I'd rather have it be part of the requirement. Maybe Package==stable? But there's also reason to do something like Package>=2.0,stable. So while pkg_resources can parse Package==stable easily enough, it's not by itself really expressive enough (I suppose Package>=2.0,==stable actually works okay). Also, there needs to be a definition of what versions are "stable". And maybe a distinction between beta/rc and development, though I'm less worried about that. Are there definitions of this? Does zc.buildout do this? -- Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org

12 years, 4 months

leading underscores in filenames

by John Hunter

I am seeing some strange behavior in files with leading underscores. I have some python extension code with names like:: src/_somefile.cpp and in my sdist they are being added in duplicate, one with the leading underscore removed. src/somefile.cpp src/_somefile.cpp This is causing easy_setup to complain at the end about not being able to remove certain files. jdhunter@bic128:mpl98.5> find . -name backend_agg.cpp jdhunter@bic128:mpl98.5> find . -name _backend_agg.cpp ./src/_backend_agg.cpp jdhunter@bic128:mpl98.5> python setup.py sdist > sdist.out jdhunter@bic128:mpl98.5> grep backend_agg.cpp sdist.out copying src/_backend_agg.cpp -> matplotlib-0.98.5.1/src copying src/backend_agg.cpp -> matplotlib-0.98.5.1/src When I run easy_install on the src tarball, I then get:: Installed /home/jdhunter/devez/lib/python2.5/site-packages/matplotlib-0.98.5.1-py2.5-linux-x86_64.egg Processing dependencies for matplotlib==0.98.5.1 Finished processing dependencies for matplotlib==0.98.5.1 Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x29bb440>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x29ba8c0>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7fe8fa2ee998>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x29bb290>> ignored Using the standard distutils with python 2.5.1

12 years, 4 months

symlinks in sourcetree sdist breaking easy_install?

by John Hunter

We are experiencing a problem related to symbolic links in our source tree/sdist that appears to breaking easy_install (using setuptools-0.6c9). To produce the bug:: jdhunter@bic128:~> PYTHONPATH=~/dev/lib/python2.5/site-packages:/home/jdhunter/devez/lib/python2.5/site-packages ~/dev/bin/easy_install --prefix=~/devez matplotlib Searching for matplotlib Reading http://pypi.python.org/simple/matplotlib/ Reading http://matplotlib.sourceforge.net Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278… Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=824… Reading http://sourceforge.net/project/showfiles.php?group_id=80706 Best match: matplotlib 0.98.5 Downloading http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtim… Processing matplotlib-0.98.5.tar.gz Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir /tmp/easy_install-qW11xj/matplotlib-0.98.5/egg-dist-tmp-QFgBsw ..snip snip [Edit setup.cfg to suppress the above messages] ============================================================================ error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or directory Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7f022cf378c0>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7f022cf35d40>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7f022ab83e18>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x7f022cf37710>> ignored jdhunter@bic128:~> The file which triggers the first error is matplotlib.conf.template, which exists in lib/matplotlib/mpl-data. There is a symlink in doc/mpl_data which points to lib/matplotlib/mpl-data. Eg in the mpl src tree:: jdhunter@bic128:mpl> ls -ld lib/matplotlib/mpl-data/ doc/mpl_data lrwxrwxrwx 1 jdhunter jdhunter 27 Jun 2 2008 doc/mpl_data -> ../lib/matplotlib/mpl-data/ drwxrwxr-x 6 jdhunter jdhunter 4096 Dec 10 13:09 lib/matplotlib/mpl-data/ When we create the sdist, here is the output matching that file:: jdhunter@bic128:mpl> python setup.py sdist > sdist.out jdhunter@bic128:mpl> grep matplotlib.conf.template sdist.out hard linking doc/mpl_data/matplotlib.conf.template -> matplotlib-0.98.5/doc/mpl_data hard linking lib/matplotlib/mpl-data/matplotlib.conf.template -> matplotlib-0.98.5/lib/matplotlib/mpl-data In the tarball, the link looks backwards to me: the tarball says lib/matplotlib/mpl-data/matplotlib.conf.template links to doc/mpl_data/matplotlib.conf.template and has zero content jdhunter@bic128:tmp> tar tvfz matplotlib-0.98.5.tar.gz |grep matplotlib.conf.template -rw-r--r-- cmoad/staff 13838 2008-12-09 17:53 matplotlib-0.98.5/doc/mpl_data/matplotlib.conf.templatehrw-r--r-- cmoad/staff 0 2008-12-09 17:53 matplotlib-0.98.5/lib/matplotlib/mpl-data/matplotlib.conf.template link to matplotlib-0.98.5/doc/mpl_data/matplotlib.conf.template If you unpack the tarball using a standard incantation, a copy is made:: jdhunter@bic128:tmp> tar xfz matplotlib-0.98.5.tar.gz jdhunter@bic128:tmp> cd matplotlib-0.98.5/ jdhunter@bic128:matplotlib-0.98.5> ls -ld doc/mpl_data/matplotlib.conf.template lib/matplotlib/mpl-data/matplotlib.conf.template -rw-r--r-- 2 jdhunter jdhunter 13838 Dec 9 17:53 doc/mpl_data/matplotlib.conf.template -rw-r--r-- 2 jdhunter jdhunter 13838 Dec 9 17:53 lib/matplotlib/mpl-data/matplotlib.conf.template I think (guess) what may be happening is that setuptools are reading the tarball using the python tarfile reader and the link is getting botched. However, I *can* read the "missing" file using tarfile:: In [17]: import tarfile In [18]: t = tarfile.open('dist/matplotlib-0.98.5.tar.gz') In [19]: o = t.extractfile('matplotlib-0.98.5/lib/matplotlib/mpl-data/matplotlib.conf') In [20]: s = o.read() In [21]: print s[:80] # MPLConfig - plaintext (in .conf format) # This is a sample matplotlib configu So I am not sure exactly what is going wrong but I think broken handling of the link is playing a role. I will probably work around this by removing the links and making hard copies myself before building the sdist and eggs, unless I hear something more intelligent from someone or come up with something better.

12 years, 4 months

problems with PyPI?

by Chris Withers

Hi All, Is anyone else having problems with PyPI? I tried mailing the catalog-sig, but my message hasn't even shown up in the archives: http://mail.python.org/pipermail/catalog-sig/ Looks like ReST isn't rendering for package descriptions, I've recently uploaded new versions of these: http://pypi.python.org/pypi/testfixtures http://pypi.python.org/pypi/mailinglogger Also, the search and front-page-newest-packages appear to be broken... Am I doing something wrong or is PyPI hosed? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

12 years, 4 months

[zc.buildout] distutils "scripts" keyword

by Pascoe, S (Stephen)

I'm coming across a lot of packages that use the distutils "scripts" keyword to identify scripts (rather than the console_scripts entry-point). Unfortunately these don't work with buildout, although they are installed with easy_install. I think this should be a solvable problem with a recipe that extends zc.recipe.egg. For instance buildbot creates the "buildbot" script. When I create a buildout with: ===================== [buildout] parts = buildbot [buildbot] recipe = zc.recipe.egg interpreter = python ===================== I can then run the script with $ bin/python -c "import pkg_resources; pkg_resources.working_set.run_script('buildbot', 'buildbot')" although I can't send it any arguments. Also the following hand-crafted script works: ================== #!/usr/bin/python import sys sys.path[0:0] = [ '/crypt/home/spascoe/expt/buildbot/eggs/buildbot-0.7.9-py2.5.egg', '/crypt/home/spascoe/expt/buildbot/eggs/Twisted-8.1.0-py2.5-linux-i686.e gg', '/crypt/home/spascoe/expt/buildbot/eggs/zope.interface-3.5.0-py2.5-linux -i686.egg', '/usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg', ] import pkg_resources pkg_resources.working_set.run_script('buildbot', 'buildbot') ================== Can anyone think of a catch that would make this not work in general? Cheers, Stephen. --- Stephen Pascoe +44 (0)1235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory -- Scanned by iCritical.

12 years, 4 months

Can Distutils handle this ?

by Benedikt.Naessens＠niko.be

Ok, Maybe I will make the question shorter : is distutils the right tool for the problems described below ? Or should I rather use a tool like InnoSetup or a Windows installer (made in .NET) ? Benedikt Naessens. I want to make a Windows installer - using distutils - for the Python code I have made so far. Related to this, I have some questions about the "best way" to do this. The project is a test platform that should be used for internal use in our company. What are my problems ? * I am using Nose, PyQt etc. : how do I make sure that these packages are installed with my installer ? The main problem is here that most of the PC's in the company are behind a firewall that not allows them to download these packages from the internet (internet browsers are handled by a remote desktop) * Maybe related to the previous issue : I have written a plugin for Nose; this plugin needs to be "registered" with Nose (manually I do this with easy_install); can I do this also with distutils ? * I am also using SWIG for some code written in C++. I have already read the documentation of distutils where they advise me to build my code with distutils. Problem is that this C++ project is already rather large and that the .pyd is already generated (so I'd rather would not like to declare all my .i and .cpp files in a setup.py file). Do I have to include the generated .pyd, .lib and .py as "package data" into setup.py or are there better ways ? Maybe this sounds trivial to a lot of you, but as I am using Python for 1.5 months, I'd like to have some help from specialists ... Thanks in advance ! Benedikt Naessens. Disclaimer This e-mail and its attachments is intended only for the person(s) or entity to which it is addressed. If you receive this e-mail by mistake, please delete this e-mail from your system and destroy all copies of it. It may contain confidential and/or privileged information. You should not copy it or use it for any purpose nor disclose its contents to any person unless allowed by a written document between the sender and the addressee.

12 years, 4 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 December 2008