Hi all,
I am just learning the basics of building Python eggs using
'setuptools'. What I have is the following code structure in a
top-down fashion:
- demo1.py
- __init.py__
- setup.py
-subpackage1
--__init.py/__
When I execute 'python setup.py bdist_egg' from the top-level
directory which has the 'setup.py' file:
__author__="amit"
__date__ ="$14 Jan, 2009 2:37:34 PM$"
from setuptools import setup,find_packages
setup (
name = 'EggDemo',
version = '0.1',
Summary = 'Just another Python package for the cheese shop',
author = 'amit',
author_email = '',
url = '',
license = '',
description= 'Long description of the package',
platform= '',
packages = find_packages(),
)
In the resulting, SOURCES.txt file, I have:
setup.py
EggDemo.egg-info/PKG-INFO
EggDemo.egg-info/SOURCES.txt
EggDemo.egg-info/dependency_links.txt
EggDemo.egg-info/top_level.txt
subpackage1/__init__.py
As you can see, the top-level 'demo1.py' is missing, even though I
have a '__init.py__' file there.
The manual at http://peak.telecommunity.com/DevCenter/setuptools#using-find-packages
makes me believe, this should work. Where am I going wrong?
Best,
Amit
--
Amit Kumar Saha
http://amitksaha.blogspot.comhttp://amitsaha.in.googlepages.com/
*Bangalore Open Java Users Group*:http:www.bojug.in
Hi,
I was wondering where I'm supposed to put a new distutils command in.
The command is a kind of bdist_rpm-like thing for my own package system,
so it's just for local use so won't ever move in Python distribution.
I thought site-packages, but just for one command, it would be a bit overkill.
Any ideas?
Hello,
I've just read distutils/README [1] which says there's "a separately packaged
standalone version of the Distutils" on Distutils web page [2].
It seems, however, this is just a unmaintained README and actually
all I could find there was old "Distutils-1.0.2".
Where can I find the latest standalone Distutils?
I looked at projects/distutils on svn.python.org but it didn't appear
to be maintained.
Thanks in advance,
[1] http://svn.python.org/view/python/trunk/Lib/distutils/README
[2] http://www.python.org/sigs/distutils-sig/
At 02:44 PM 1/15/2009 +0100, Eric Lemoine wrote:
>Hi
>
>For a project I'm involved in we created our own package index. The
>package index includes our package (mapfish), as well as its direct
>and indirect dependencies.
>
>Then, the installation of the "mapfish" package and its dependencies
>is done with this command:
>easy_install -i http://dev.camptocamp.com/packages/mapfish/1.0/index
>mapfish==1.0
>
>The installation command works, but some indirect dependencies aren't
>downloaded from our package index but from other sources. For
>example,"simplejson" which "pylons" depends on (which "mapfish"
>depends on), is downloaded from
>"http://pylons.cachefly.net/download/0.9.6.2/simplejson-1.7.1-py2.5.egg"
>as opposed to be downloaded from
>"http://dev.camptocamp.com/packages/mapfish/1.0/simplejson-1.7.1.tar.gz".
Binary packages are given precedence over source packages, and
presumably Pylons is providing a direct link in its setup.py.
>We'd like every mapfish dependency to be downloaded from our package
>index. Does anyone know how to achieve this?
You'll need to either ensure that your index provides binaries, or
use --allow-hosts to restrict what hosts easy_install will look for files on.
Hi
For a project I'm involved in we created our own package index. The
package index includes our package (mapfish), as well as its direct
and indirect dependencies.
Then, the installation of the "mapfish" package and its dependencies
is done with this command:
easy_install -i http://dev.camptocamp.com/packages/mapfish/1.0/index
mapfish==1.0
The installation command works, but some indirect dependencies aren't
downloaded from our package index but from other sources. For
example,"simplejson" which "pylons" depends on (which "mapfish"
depends on), is downloaded from
"http://pylons.cachefly.net/download/0.9.6.2/simplejson-1.7.1-py2.5.egg"
as opposed to be downloaded from
"http://dev.camptocamp.com/packages/mapfish/1.0/simplejson-1.7.1.tar.gz".
We'd like every mapfish dependency to be downloaded from our package
index. Does anyone know how to achieve this?
Thanks a lot,
--
Eric
Hi list
I'm a little bit confused with the buildout configuration files, and i
can't find any useful information. I get that every part of the buildout
has a recipe and this recipe takes some configuration options. My
question is ...how can i know which are those options? I went through
the code and found most of them, but not all.
For example, since i'm running on Debian i would like to use buildout +
dzhandle, so i need plone.recipe.dzhandle. I found some configuration
options used explicitly in the code (locationtype, location, zopetype,
version, zope2-location, zopeuser, zcml, serviceuser and instancename),
but i also found in an example buildout configuration file «httpport»
(obvious what it is used for) and «threads» (not that obvious for me :)
). Also i would like to know which other options i can use to set, for
instance, dzhandle «--addon-mode» that is mandatory when using dzhandle
alone.
Maybe this is very simple, i recognize that my knowledge of python is
not as good as it should be...yet ;). Anyways, any hint would be useful
for me.
My english is not very good :(, my apologies.
Thanks & happy new year! :)
At 02:11 PM 1/12/2009 +0100, Tarek Ziadé wrote:
>Ok, I will introduce in my patch the other formats. I am wondering though, how
>far this would be from an integration of pkg_resources into Distutils/pkgutil,
>with some API on the top and if it makes sense.
It makes sense to me, I just wanted you to be aware how deep a job it
is. You're probably going to need a generic function by importer
type, just like the others in pkgutil.
>The only difference I can see is that I am working on an API that would return
>DistributionMetadata instances
>
>http://bugs.python.org/file12692/get_metadata.diff
Yep... which means that you're going to have to reinvent (and
re-test) a fair number of wheels to get there. pkg_resources just
lets you ask for a distribution's PKG-INFO metadata, and get it back
as a string, regardless of what egg format is in use (including
distutils). But to *just* support PKG-INFO, the irony is that you'll
have to recreate a fair amount of stuff.
>I'd say then : if setutpools version parsing system is superior to
>distutils.versionpredicate,
I'm not actually familiar with "versionpredicate", so I couldn't
say. It's definitely superior to LooseVersion and StrictVersion,
which were the only version tools available in the distutils when I
started all this.
>wouldn't it make sense to merge it into Distutils ?
>
>Maybe that was the initial plans ?
Yes, and yes. Setuptools version parsing (and name/version escaping)
functions at least doesn't have any dependencies on anything
else. So that's an easy port. If you want Requirement objects as
well (specifying various version ranges), a bit more gets pulled
in. However, if all you want is to be able to turn versions into
opaquely-comparable values, parse_version() and its dependencies are
all you need.
(By the way, I previously proposed PEP 365 -- that pkg_resources
simply be bundled in the stdlib -- to address these needs.)
>Well, being able to query the installed version for a package seem to
>me like a feature
>that should live in Distutils or pkgutil
>
>In the same way, being able to do version arithmetic is rather
>important, and it would be better
>ihmo to have one and only one way to deal with that in Python,
>
>What are you plans for Setuptools development for the future ?
I hope someday to have some time for it again. :)
At 01:52 PM 1/14/2009 +0200, bl8cki wrote:
>To avoid removing added things in working_set ... i remove the entry
>for which i need to switch versions in easy-install.pth and then
>only 'resolve'-ing and 'add'-ing to the working_set.
>
>I don't know if this (removing the lines in easy-install.pth) will
>reflect on easy_install to work properly, but for now i'm happy with
>this solution :)
>
>Still will be very thankful for any comments and suggestions.
"easy_install -m projectname" will remove the line for you. For that
matter, using -m when you install those eggs in the first place will
also do the trick.
Hello all,
I would like at runtime to change the used version of installed egg ... (for
example based on some condition import specific version)
and the only solution i end up with is to remove from the 'working_set'
'by_key' hash the best matched version, added when importing pkg_resources,
and then 'resolve' the wished one and add it. otherwise i end up with
version conflict.
I do not want to add version in package naming (package_0_1) ... but that
would be the fastest solution :)
What's the best thing i can do?
Thanks!
At 08:22 PM 1/11/2009 +0100, Tarek Ziadé wrote:
>On Sat, Jan 10, 2009 at 9:09 PM, Phillip J. Eby <pje(a)telecommunity.com> wrote:
> >>
> >> Since this is basically what has been done in setuptools, I thaught
> >> that you might wanted to help around for this change ?
> >
> > I'd suggest looking at the pkg_resources code, particularly
> > find_distributions and its related functions.
>
>Ok thanks,
>
> > Note, for example, that egg
> > layouts can be nested (even when zipped!), and that the metadata can have
> > different filenames, depending on the installation format.
>
>This is my understanding at this stage :
> From a Distutils point of view, it seems that this would suffice to
>read the metadata from the egg-info files :
>
>1/ add in distutils.dist.DistributionMetadata a new method to be able
>to load an existing egg-info file
>2/ add in the pkgutil module, the get_metadata function, that could
>have this signature:
>
> get_metadata(package_name, path_item)
>
>where path_item is a site-packages like directory,
>
>this function would scan the path_item directory, like what
>setuptools.pkg_resource code does,
>and return the metadata (+fill a cache with all packages metadata found)
My point was that if you don't support .egg files or
EGG-INFO/PKG-INFO, then your API is rather crippled; there is no
reason for anyone using setuptools to use it in place of the
corresponding pkg_resources API, as it simply will not work with
packages installed by easy_install.
> > Version parsing
> > also has certain peculiarities, which also means that people doing simple
> > string comparisons on the version field is probably not going to suffice.
>
>Wouldn't distutils.versionpredicate be useful here ?
Only if the package in question follows distutils' rules, which
aren't as flexible as those of setuptools... and setuptools' version
parsing system was designed to handle a significant number of
versioning schemes that were in use on PyPI at the time -- schemes
that the distutils mostly couldn't parse correctly.
I'm just trying to warn you that adding these features in a
distutils-only way could easily end up like the PKG-INFO "requires"
and "provides" fields -- that is, theoretically useful but of no
practical value to anyone. In fact, they could be "attractive
nuisances" in that they would encourage people to use them, only to
find out later that it was a complete dead end because of the lack of
support for anything but pure-distutils packages.
Of course, they will then blame me and setuptools rather than you and
the distutils, but I suppose I'm used to that. ;-)
