I'd like to start using the PackageIndex class. For now, I want to use:
- The constructor (of course)
- prescan and
- __getitem__.
I imagine I'll use other methods in the long term. I'd be happy to
document these as I go.
Is there any problem with considering these public?
As I mentioned the other day, my plan to to make more use of
setuptools and less use of easy_install in zc.buildout, until I
eventually don't use easy_install at all.
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
Howdy,
I am trying to provide myself an interface to a C module from python, using
pyrex as the glue. I think I have all the C and pyrex correct, but am
trying to figure out how to build it (on Mac OSX with Python 2.4 and gcc
3.3). My web search suggests that disutils is the proper way to build such
a thing, even though I don't intend to distribute it to anyone but myself.
But I am having a hard time sorting through all the documentation on
distutils, attempting to separate the irrelevent from relevent.
I have a directory containing my myfunc.c, myfunc.h and c_myfunc.pyx. What
else do I need to do so that I can use distutils to build this and then
access the functions in this module from another python program?
Thanks for any help.
Bob H
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
I need to install a package that depends on an external non-python
library. I need to be able to specify the locations of the library's
include and library files. Normally, when invoking setup.py myself,
I'd pass these using the --include-dirs and --library-dirs options.
Is there any way to pass this information to easy_install?
Note that the package in question doesn't use setuptools, but I want
an egg as a result. The only way I know how to do that is with
easy_install.
One hack I can think of is to use --editible and --build-directory to
download the package, write a setup.cfg into the resulting directory
and then run easy_install on the result. I would hope though that
there is a better way. :)
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
Hi,
Several python packages, such as Numeric, will install header files
during installation. It seems to me that the best way to support this
in a world of eggs is to add those include files to eggs and teach
setuptools to use those includefiles in build_ext.
The attached patch does just that. It adds an egg_info.writer that
writes all distribution.headers to the egg-info directory and patches
build_ext to add header files from all active distributions to the
include path.
I'm not entirely sure that this patch is correct, although it seems
to work just fine. The egg_info.writer for include files adds a
directory with files to the meta-data, the documentation and API seem
to assume that writers will write a single file. The patch to
build_ext feels hackish and I'm not sure if adding all active
distributions is the right thing to do, maybe only header files from
distributions that are mentioned as setup_requires should be added.
That would avoid possible problems during upgrades of packages.
Ronald
At 08:18 PM 8/4/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>I'm using setuptools interface to fetch packages from PyPI. Version
>requirements work fine, but more sophisticated conditions are needed.
>In particular, I would like to hint setuptools to prefer source
>distributions (tar/subversion/..) over eggs and prefer fetching
>distributions from PyPI over relying on locally installed releases
>(even if version numbers match). Currently my code looks something
>like that:
>
>from setuptools.package_index import PackageIndex
>from pkg_resources import Requirement
>
>pkgindex = PackageIndex()
Pass an empty search path, e.g. PackageIndex(search_path=[])
This will create an index that doesn't include any installed eggs.
>path = pkgindex.fetch(Requirement.parse(REQUIREMENTS),
> TMP_DIR, force_scan=True)
>
>According to documentation, setting force_scan to False would inhibit
>checking local filesystem,
I don't know where you're getting that from. The docstring says:
"""If necessary, or if the `force_scan` flag is set, the requirement is
searched for in the (online) package index as well as the locally
installed packages."""
Note the "as well as". Anyway, creating the PackageIndex with search_path
set to an empty list should do what you want, except you also want to pass
'source=True' to 'fetch()' if you want it to find only source packages.
Hi,
I think the 'develop' command should bootstrap 'setuptools' itself --
like 'install' does.
I was Googling around for a possible work-around, but instead I only
found others who ran into the same problem:
http://www.djangoproject.com/documentation/install/
(See the comments at the bottom of the page.) They try to use 'develop'
to install Django, but get "ImportError: No module named pkg_resources"
when they try to run it. (Come to think of it, I may have used 'develop'
to install Django the first time, but it only worked because I had used
'setuptools' before.)
The users of my 'setup.py' script will likely encounter the exact same
scenario: their first encounter with 'setuptools' will be checking-out a
project from Subversion, and then running "setup.py develop".
Anyway, I developed a crude work-around -- just force the setuptools egg
to be installed, before calling setup() for real:
import setuptools
if setuptools.bootstrap_install_from:
egg = setuptools.bootstrap_install_from
setuptools.bootstrap_install_from = None
setuptools.setup(script_args=['easy_install', egg])
setuptools.setup(...)
(The above snippet has no warranty of any kind.)
--Leif Strand
Hi,
I'm using setuptools interface to fetch packages from PyPI. Version
requirements work fine, but more sophisticated conditions are needed.
In particular, I would like to hint setuptools to prefer source
distributions (tar/subversion/..) over eggs and prefer fetching
distributions from PyPI over relying on locally installed releases
(even if version numbers match). Currently my code looks something
like that:
from setuptools.package_index import PackageIndex
from pkg_resources import Requirement
pkgindex = PackageIndex()
path = pkgindex.fetch(Requirement.parse(REQUIREMENTS),
TMP_DIR, force_scan=True)
According to documentation, setting force_scan to False would inhibit
checking local filesystem, but it's not working that way. Can you
suggest anything that would help me in achieving what I described?
Cheers,
mk
--
. o . >> http://joker.linuxstuff.pl <<
. . o It's easier to get forgiveness for being wrong
o o o than forgiveness for being right.
If an error occurs on the first download attempt, the subsequent attempts
by easy_install to download a file can't be properly interrupted with
Control-C (instead of terminating the process, it just jumps to the next
of ten or fifteen mirrors). Here's the fix:
---
/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py~ 2006-08-03 20:04:28.000000000 +0000
+++
/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py 2006-08-03 20:21:18.000000000 +0000
@@ -589,6 +589,8 @@
url = urlparse.urlunparse((scheme, mirror, path, param, '', frag))
try:
return self._download_to(url, filename)
+ except (KeyboardInterrupt,SystemExit):
+ raise
except:
_sf_mirrors.remove(mirror) # don't retry the same mirror
mirror = get_sf_ip()
John
Somebody reported to me that one of my project releases [1] has suddenly
stopped being installable for people who don't already have setuptools
installed.
The breakage occurred because the recommended method for providing a
bootstrap (bundling ez_setup.py -- or FWIW, ez_setup/__init__.py, in my
case) at least as of setuptools-0.6a11, unconditionally fetches the
version of setuptools whose version number is embedded in ez_setup.py.
That now fails for 0.6a11, because that version has been removed from
PyPI.
Obviously people trying to install this old release of mine can still
install setuptools manually by downloading ez_setup.py themselves. But it
would be nice if in future, the bootstrap were clever enough to fetch a
directory listing and then grab the latest setuptools release.
Otherwise, project releases that were very easy to install in the past
suddenly become more complicated to install just because the PyPI
setuptools download area has been cleaned up.
[1] http://wwwsearch.sourceforge.net/ClientCookie/src/ClientCookie-1.3.0.tar.gz
John
At 06:49 PM 7/3/2006 +0200, Matthias Klose wrote:
>Phillip J. Eby writes:
> > At 10:28 PM 6/9/2006 +0200, Matthias Klose wrote:
> > >Phillip J. Eby writes:
> > > > At 09:51 PM 6/9/2006 +0200, Matthias Klose wrote:
> > > > >Hi,
> > > > >
> > > > >when installing an egg in a system-installed python version, then you
> > > > >do have another python version information in the egg_info directory
> > > > >name (py2.x). Is it possible or advisable to exclude that information
> > > > >from the name? At least I know that I'm installing into
> > > > >/usr/lib/python2.3/site-packages.
> > > >
> > > > I don't understand your question. There is no 'egg_info'
> directory. Are
> > > > you talking about a .egg/EGG-INFO directory or an '.egg-info'
> directory?
> > >
> > >sorry,
> > >
> > > /usr/lib/python2.3/site-packages/setuptools-0.6b2-py2.3.egg-info
> > >
> > >would it be safe to rename that to
> > >
> > > /usr/lib/python2.3/site-packages/setuptools-0.6b2.egg-info
> > >
> > >without loosing functionality?
> >
> > Yes.
>
>what about installing the .egg-info directory without version
>information when --single-version-externally-managed is used?
Note that the .pyc files will be built for a specific Python version;
that's why the version number is there. Not including the version number
won't magically make it work with other Python versions.
>Another unrelated thing: Debian is supposed to ship the source code
>for binaries, but it's not included in the package for cli.exe and
>gui.exe. Could you point me to the source code and/or include it in
>the next release?
It's included in the source release, along with all the documentation. The
file you're looking for is 'launcher.c'. Of course, the .exe files aren't
used on non-Windows platforms anyway.