I want to be able to do things such as:
from mortar import content
from mortar.sqlalchemy import storage
...but where mortar is distrubuted as one package and mortar.sqlalchemy
(and a whole lot more like it...) are distributed as seperate packages.
Is this possible?
Simplistix - Content Management, Zope & Python Consulting
I'm getting a growing number of customer-specific and non-open-source
eggs. I used to just put these in as svn:externals and then add the path
in as a develop egg, however, I'm not sure this is going to scale.
What I'd like to do is have a "local egg repository" that I can put
these eggs in and then just point buildout at it.
Has anyone done this before?
Failing that, is there any way in buildout to say "use this egg
repository in favour of pypi, and only look at pypi if the egg isn't
found in the local repository"?
Also, does anyone have any software that makes a good egg repository?
Does anyone have anything that supports the equivalent of:
python setup.py upload
...but to a local repository?
Simplistix - Content Management, Zope & Python Consulting
Your __init__.py and domstripper.py need to be moved into a
subdirectory named domstripper.
At 11:27 PM 11/18/2008 +0000, Peter Bengtsson wrote:
>Sorry about the vague subject but I'm not sure how to phrase my problem.
>First of all I'm a setuptools beginner and I'm not sure what I'm doing.
>I've created a basic package with paster and filled in the blanks. Now
>python setup.py test works and runs the two little tests it has.
>I might have "pressed one too many buttons" when I ran setup.py which
>might be why it doesn't work.
>It's available on http://pypi.python.org/pypi/domstripper/
>But when I do this:
>(my_virtualenv)$ easy_install domstripper
>(my_virtualenv)$ ls lib/python2.5/site-packages/
>it installs fine as far as I can see but here's the problem::
> (my_virtualenv) $ python
> >>> import lxml # just to test that something worked
> >>> import domstripper
>Grateful for advice.
Sorry about the vague subject but I'm not sure how to phrase my problem.
First of all I'm a setuptools beginner and I'm not sure what I'm doing.
I've created a basic package with paster and filled in the blanks. Now
python setup.py test works and runs the two little tests it has.
I might have "pressed one too many buttons" when I ran setup.py which
might be why it doesn't work.
It's available on http://pypi.python.org/pypi/domstripper/
But when I do this:
(my_virtualenv)$ easy_install domstripper
(my_virtualenv)$ ls lib/python2.5/site-packages/
it installs fine as far as I can see but here's the problem::
(my_virtualenv) $ python
>>> import lxml # just to test that something worked
>>> import domstripper
Grateful for advice.
It appears to me as if the behavior of parse_version('dev') has changed with
setuptools-0.6c9, but this change is not documented on the setuptools
documentation. Assuming pv=parse_version, the documentation implies that
pv('a') < pv('b') < pv('c') == pv('rc') < pv('d') == pv('dev'). but it turns
out that pv('dev') == pv('@') < pv('a').
I suggest the documentation say something like the following:
A pre-release tag is a series of letters that are alphabetically before
"final". Some examples of prerelease tags would include alpha, beta, a, c,
dev, and so on. You do not have to place a dot before the prerelease tag if
it's immediately after a number, but it's okay to do so if you prefer. Thus,
2.4c1 and 2.4.c1 both represent release candidate 1 of version 2.4, and are
treated as identical by setuptools.
In addition, there are three special prerelease tags that are treated as if
they were the letter c: pre, preview, and rc. So, version 2.4rc1, 2.4pre1
and 2.4preview1 are all the exact same version as 2.4c1, and are treated as
identical by setuptools.
Furthermore, dev is a special tag that is always less than any other
character tag. It is treated as the equivalent of the character '@'.
I am using python Release 2.3.3, but I cant use it solving the following python source code. Would you please help me in solving the following problem using some other python release.
Consider the following Python code: def expo(s,lm,N): return reduce(lambda x,m: pow(x,m,N),lm,s) def hamming(a): return a>0 and (a%2)+hamming(a/2) or 0 def htot(k): n=pow(2,k) N=pow(2,n)-3 lm=[pow(i,i,N) for i in range(1,n+1)] lz=[expo(3,lm[:j]+lm[j+1:],N) for j in range(n)] return sum([hamming(z) for z in lz])
The function htot gives the following result for small values of k: >>> [htot(i) for i in range(3,8)][35, 122L, 540L, 2068L, 8070L]
You are scincerely asked to compute the value of function htot for larger values of k. Go as far as you can.
I am expecting your fast respond.
With Best Regards.
Hi all :)
I would like to support options like "--localedir" in my setup.py, and
- Support the option in setup.py. Easy, just subclassing and appending
the option to the proper "user_options". Worst part is that I would
have to subclass both "build_scripts" and "install_data" for this to
work. More on that below.
- Changing the hardcoded path into the main script, so the proper path
is given to "bindtextdomain()". I suppose I have to subclass
"build_scripts" for this, run sed or whatever to modify the script
code with the specified paths, etc.
- Install the files to the user-specified location. This means I have to
subclass "install_data" for this, to put the translation files where
the end-user wants me to do.
At first I was ready to do the above, but then I thought of a big
problem (I'm used to autoconf's './configure', and this problem doesn't
happens with it): the end-user may run, by mistake, "setup.py build
--localedir=mylocaledir" first and "setup.py install" after that, and
that means that the script will look for the translations into
"mylocaledir", but translations will be installed in
Then I thought: no problem. I won't touch any "build" subclass and will
do the modifications at installation time, subclassing only
"install_scripts" and "install_data". Then again, both commands are
independent and if the user forgets to pass "--localedir" to any of
them, the installed script won't work properly.
The same problem happens with any data that the script have to access
and whose path can be only determined at installation time (icons, for
Right now I only have these choices, if using distutils:
- Forget "--localedir" and use the default options (--install-data, for
example). This doesn't solve my problem, because as soon as the user
installs the program using separate "install_scripts" and
"install_data" commands, it's impossible to put the proper directory
into the script because the destination directory for data files won't
be known when installing the scripts.
- Use hardcoded, FHS compliants directories for translations and icons,
and hope that new data types I may need in the future have such FHS
compliant directories. This means that my script will try to find the
data in /usr/whatever and /usr/local/whatever (and maybe under
/opt/package/whatever), so any installation outside those directories
won't work. This looks like the more frequent solution, from what I've
- Use a self made "setup.py" that doesn't use distutils at all.
Tempting, but right now I'm not like reinventing wheels. Moreover,
I've already read half of the code of distutils to know what to
subclass and how, and I would like to use distutils if possible.
So, my question is: is there any "official" way of doing what I want?
That is, treating the script as a template and put the proper paths
there, no matter what combination of "build_*" and "install_*" commands
are used. I could live by using hardcoded paths, but that's not the way
I've done things in the past (when using autoconf, CMake, MOBS, etc.)
and I don't feel comfortable with it.
I've googled with no result, and I'm afraid that people use hardcoded
paths or their own search functions to find the data once it is
Thanks a lot in advance :)
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...
I can't submit anymore dists for one of my eggs.
Pypi returns me HTTP/500 error either if i submit TTW or via sdist upload.
Am i alone to encounter the problem?
GPG Key FingerPrint: 0x1A1194B7681112AF
There are two things that cause a lot of people to object to the use
of setuptools: that it changes the semantics of PYTHONPATH, and that it
doesn't work when you run "setup.py install --prefix=somedir".
This pair of patches addresses the second issue: that when you run
"python ./setup.py install --prefix=somedir" it doesn't work like
distutils does. It is possible to work-around this in various ways
(either with --svem --record or with mkdir -p and PYTHONPATH before
invoking setup.py) but the existence of these work-arounds does not
seem to be sufficient to make some people accept the use of setuptools
[1, 2, personal correspondance from my "Why do you hate setuptools?"
These patches make setuptools behave more like distutils in this
I know that you had good reason to do these sanity checks in the first
place, PJE, but I hope that you will consider accepting these patches
in order to extend setuptools's reach.
Sat Nov 15 12:04:20 MST 2008 zooko(a)zooko.com
* try to mkdir the install directory
This eases the common use case of "./setup.py install --
and makes setuptools behave more like distutils in this case.
@@ -249,6 +249,14 @@
instdir = normalize_path(self.install_dir)
pth_file = os.path.join(instdir,'easy-install.pth')
+ # mkdir it if necessary
+ except OSError:
+ # Oh well -- hopefully this error simply means that it
is already there.
+ # If not the subsequent write test will identify the
# Is it a configured, PYTHONPATH, implicit, or explicit
is_site_dir = instdir in self.all_site_dirs
Sat Nov 15 12:05:01 MST 2008 zooko(a)zooko.com
* change exception into warning when target install dir isn't pth-
This eases the common use case of "./setup.py install --prefix=foo"
followed by some other mechanism to make sure that ./foo/... is
importable, and makes setuptools behave more like distutils in
@@ -276,7 +276,7 @@
if not is_site_dir and not self.multi_version:
# Can't install non-multi to non-site dir
- raise DistutilsError(self.no_default_version_msg())
if self.pth_file is None:
@@ -1059,7 +1059,9 @@
-Please make the appropriate changes for your system and try
again.""" % (
+Proceeding to install. Please remember that unless you make one of
+these changes you will not be able to run the installed code.
+""" % (
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month