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.
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…
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
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
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
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.
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.
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.