At 11:44 AM 01/19/2006 -0500, Charlie Moad wrote:
>I tried the "." and I keep getting:
>
>error in basemap setup command: Distribution contains no modules or
>packages for namespace package 'matplotlib.toolkits'
Great, now we're making progress. :) Can you post your setup.py? It
sounds like you don't have 'matplotlib.toolkits' listed in your 'packages'
keyword, or perhaps there's something amiss with your package_dir or something.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I tried adding the test command to my setuptools-enhanced build process.
And I got "python setup.py test" to work on Windows, now when I'm on
Linux it fails.
I *think* that it was in both cases the latest version of setuptools.
You should be able to verify it with these sources:
svn co http://initd.org/svn/pysqlite/pysqlite/trunk/ pysqlite_trunk -r 202
Oh, you need SQLite version 3.2.2 or later to build this pysqlite project.
This is the full output:
gerhard@lara:~/src/svn/pysqlite/trunk$ python setup.py test
running test
running egg_info
writing requirements to pysqlite.egg-info/requires.txt
writing pysqlite.egg-info/PKG-INFO
writing top-level names to pysqlite.egg-info/top_level.txt
warning: manifest_maker: standard file not found: should have one of
README, README.txt
reading manifest template 'MANIFEST.in'
writing manifest file 'pysqlite.egg-info/SOURCES.txt'
running build_ext
copying build/lib.linux-i686-2.4/pysqlite2/_sqlite.so -> lib
Traceback (most recent call last):
File "setup.py", line 151, in ?
main()
File "setup.py", line 137, in main
classifiers = [
File "/usr/lib/python2.4/distutils/core.py", line 149, in setup
dist.run_commands()
File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command
cmd_obj.run()
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/test.py",
line 59, in run
self.run_tests()
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/test.py",
line 73, in run_tests
unittest.main(None, None, [unittest.__file__]+self.test_args)
File "/usr/lib/python2.4/unittest.py", line 758, in __init__
self.parseArgs(argv)
File "/usr/lib/python2.4/unittest.py", line 785, in parseArgs
self.createTests()
File "/usr/lib/python2.4/unittest.py", line 791, in createTests
self.module)
File "/usr/lib/python2.4/unittest.py", line 556, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python2.4/unittest.py", line 532, in loadTestsFromName
parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test'
- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD0A/HdIO4ozGCH14RAu1YAJkBQmM/QyuDvCbJEhQ71ggBsy3Y1QCghUee
K2b9G/o1QIKqKLWUezRezQw=
=RuvI
-----END PGP SIGNATURE-----
Hi,
I've come across a problem with an easy_install managed package
(matplotlib) on my OS X box. When I try to import it for the first
time inside of a twisted application I get this nasty traceback:
Traceback (most recent call last):
File "/Users/mtt/Desktop/twisted_macosx_vers.py", line 12, in ?
reactor.run()
File "/usr/local/lib/python2.4/site-packages/twisted/internet/posixbase.py",
line 206, in run
self.mainLoop()
File "/usr/local/lib/python2.4/site-packages/twisted/internet/posixbase.py",
line 214, in mainLoop
self.runUntilCurrent()
--- <exception caught here> ---
File "/usr/local/lib/python2.4/site-packages/twisted/internet/base.py",
line 541, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/Users/mtt/Desktop/twisted_macosx_vers.py", line 4, in get_platform
import pkg_resources
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 534, in ?
class Environment(object):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 537, in Environment
def __init__(self,search_path=None,platform=get_platform(),python=PY_MAJOR):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 147, in get_platform
version = _macosx_vers()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 126, in _macosx_vers
info = os.popen('/usr/bin/sw_vers').read().splitlines()
exceptions.IOError: [Errno 4] Interrupted system call
This seems to be caused by twisted's signal handling, which breaks
os.popen (and subprocess), see this bug:
http://twistedmatrix.com/bugs/issue733
I've attached a simple test script which triggers the problem (most of
the time for me, you have to run it a few times as it doesn't always
crash).
I've got a work around though:
If I import pkg_resources before starting my twisted app it seems to
fix the problem. (I presume that get_platform's output is being kept
somewhere, Environment's __init__ args I think.)
cheers,
Michael
Hi,
I've started using setuptools as a developer quite recently, and
appreciate the extra features. I've a question though, regarding the way
dependencies are resolved when installing such a package: I've written a
package that uses elementtree, and would have found natural to add it in
install_requires. However, I've already installed it as a debian
package, and in the current state setuptools tries to reinstall over it.
So, should I add some extra logic to the setup.py script (ie, try the
dependencies myself) or is there a way to tell it "don't update the
dependence if you can already import the module" in a convenient way?
Frédéric
--
Frédéric Gobry Infoscience
SISB / EPFL
Tel: +41216932288
http://people.epfl.ch/frederic.gobry
At 01:35 PM 01/18/2006 -0500, Charlie Moad wrote:
>Following the instruction for setuptools, I am trying to make
>matplotlib and basemap (a mpl toolkit) share the namespace
>"matplotlib/toolkits". I can build and install the eggs no problems.
>"matplotlib/toolkits" is in both's "EGG-INFO/namespace_packages.txt"
It should be matplotlib.toolkits, not matplotlib/toolkits.
>files. I have added __init__.py files with
>"__import__('pkg_resources').declare_namespace(__name__)" in both the
>mpl and basemap matplotlib/toolkits folders. Basically I have done a
>ton of playing around and "from matplotlib.toolkits import basemap"
>will not work. It is always limited to the scope of the matplotlib
>egg which it is hitting first.
Did you run "setup.py develop" or "setup.py install" in both projects?
> Are the docs not reflective of the
>0.6a9 release? Any help is greatly appreciated.
AFAIK, the docs are correct. If you can point me to the source code for
your packages I can take a look at them.
Following the instruction for setuptools, I am trying to make
matplotlib and basemap (a mpl toolkit) share the namespace
"matplotlib/toolkits". I can build and install the eggs no problems.
"matplotlib/toolkits" is in both's "EGG-INFO/namespace_packages.txt"
files. I have added __init__.py files with
"__import__('pkg_resources').declare_namespace(__name__)" in both the
mpl and basemap matplotlib/toolkits folders. Basically I have done a
ton of playing around and "from matplotlib.toolkits import basemap"
will not work. It is always limited to the scope of the matplotlib
egg which it is hitting first. Are the docs not reflective of the
0.6a9 release? Any help is greatly appreciated.
Thanks,
Charlie
I have a Python module for doing MCMC simulation that requires a
number of prerequisite packages to run, all of which are open source
(so I can build and distribute the packages that are needed). I am
wondering if there is a way to use the power of python eggs to be
able to have a single installer that installs or updates all the
required packages. Is there a way of having the egg installer for my
package go ahead and fetch the eggs of the prerequisite packages and
install them?
Thanks,
C.
--
Christopher J. Fonnesbeck
Population Ecologist, Marine Mammal Section
Fish & Wildlife Research Institute (FWC)
St. Petersburg, FL
Adjunct Assistant Professor
Warnell School of Forest Resources
University of Georgia
Athens, GA
T: 727.235.5570
E: chris at trichech.us
I've got shared libraries working on Windows and Linux -- without any
LD_LIBRARY_PATH nonsense, or any .so file rewriting. I have not had a
chance to try this on OS X, however. If there's anybody out there who has
experience wrestling with the Mac OS linker (hi, Bob! <wink>) has a chance
to try it out and maybe tweak it a little bit, I'd appreciate it.
The code is in the subversion trunk now, and the source includes a
tests/shlib_test subdirectory that you can change to and run "setup.py
test" to build/link/test, e.g.:
cd tests/shlib_test
PYTHONPATH=../.. python setup.py test
This just verifies that the basic linking works, i.e., whether my guesses
for the linker options in build_ext.py were correct. The second test is to
verify that it works from a different directory:
cd ..
PYTHONPATH=..:shlib_test python -c "import hello"
If this works without crashing, then the dynamic linking works even from a
different directory.
Based on my limited guesswork, the final test is the one most likely to
fail on OS X (assuming the link step succeeded, and I'm not sure it
will!). Rename the test directory temporarily:
mv shlib_test something_else
PYTHONPATH=..:something_else python -c "import hello"
mv something_else shlib_test
If this works without a bit of hacking, I'll be rather surprised, but
*very* pleased. If all three tests work without any changes to the source,
it's probably a bug. ;) (Specifically, it probably means setuptools fell
back to static linking, and thus isn't having any dynamic link problems.)
The basic idea of what I'm doing here is that I try to set the runtime
library search path of each extension (that depends on a shared library in
the project), to include the current directory *at runtime*, then make a
Python wrapper for the extension that temporarily changes the current
directory while doing the import.
The tricky bit -- if I understand correctly -- is that OS X has no concept
of a runtime library search path, so what this probably *should* be doing
is specifying something like "-dylib_file
libhellolib.dylib:./libhellolib.dylib" in the link options for the 'hello'
extension. What I'm not clear on is whether this is actually allowed by
the linker, or if it even does what I think it does in the first
place. Even if it's allowed and does the right thing, I have a sneaky
suspicion that perhaps the path will be converted to an absolute path at
link time, rather than leaving the './' in place, given the general
reputation for deviousness possessed by the Mac OS linker. :)
On the other hand, perhaps it's possible to fudge the paths in the dylib
once it's built, such that the './' is in the file? Any thoughts or
suggestions would be welcome.
In a couple of weeks I'll have a chance to play around with this on a Mac
myself, but since I'm starting from scratch (zero Mac experience
whatsoever), I'm hoping maybe someone more experienced could provide some
degree of guidance by then. Thanks.
(readding distutils-sig which I accidentally dropped)
On 1/16/06, Christopher Fonnesbeck <chris(a)trichech.us> wrote:
> On Jan 16, 2006, at 11:54 AM, Kevin Dangoor wrote:
>
> > Yes. This is something setuptools does quite admirably. This is in the
> > setup.py for TurboGears:
> >
> > install_requires = ["TurboKid >= 0.9.0",
> > "CherryPy > 2.1.1",
> > "SQLObject >= 0.7.1dev_r1457", "simplejson >= 1.1",
> > "elementtree >= 1.2.6", "PasteScript >= 0.4.1",
> > "cElementTree >= 1.0.2", "FormEncode >= 0.4",
> > "setuptools >= 0.6a8",
> > "RuleDispatch"],
> >
> > Running easy_install on the TurboGears package will go and fetch all
> > of those pre-requisites.
> >
> > So, easy_install is the installer, and your egg includes the metadata
> > about which packages it needs.
>
> This is what I was hoping. What about URLs? The packages dont have to
> be in the cheese shop, do they?
Nope. TurboGears uses some packages that aren't in the Cheeseshop. You
can use the -f/--find-links option to tell easy_install where to look.
You can see the TurboGears installation instructions to see the full
process:
http://www.turbogears.org/download/index.html
Generally, pretty easy. If you have all of the eggs available on your
local machine, you can also have setuptools run with those eggs.
Kevin
Has a decision been made whether to include setuptools in 2.5?
If it is going to be included, then I'll update doctest to
use pkg_resources to find doctest text files. If it isn't going to
be included then I'll have a quandry. :) I guess that in that case,
I'd have to use some conditional logic.
Jim
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.comhttp://www.zope.org
