Mailman 3 November 2008 - Distutils-SIG

namespace packages question
by Chris Withers 21 Nov '08

21 Nov '08

Hi All, 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? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 1

[buildout] private eggs and egg repositories
by Chris Withers 20 Nov '08

20 Nov '08

Hi All, 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? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

6 22

Re: [Distutils] Seems to work except it won't import
by Phillip J. Eby 19 Nov '08

19 Nov '08

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/ >lxml-2.1.3-py2.5-linux-i686.egg >domstripper-0.2dev_r16670-py2.5.egg >setuptools-0.6c8-py2.5.egg >easy-install.pth >setuptools.pth > > >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.

2 1

Seems to work except it won't import
by Peter Bengtsson 18 Nov '08

18 Nov '08

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/ lxml-2.1.3-py2.5-linux-i686.egg domstripper-0.2dev_r16670-py2.5.egg setuptools-0.6c8-py2.5.egg easy-install.pth setuptools.pth 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. -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com

1 1

new behavior of parse_version('dev')?
by Jason R. Coombs 18 Nov '08

18 Nov '08

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 '@'. Any objections?

1 0

question about python
by Kalkidan Aweke 18 Nov '08

18 Nov '08

Dear sir/maddam 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. Exponentiation 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. Kalkidan Aweke +251911505062 Addis Ababa Ethiopia

1 0

setuptools Windows installer for Python 2.6
by Abhigyan Agrawal1 18 Nov '08

18 Nov '08

Hi, I am wondering if there is any plan to release a windows installer for setuptools setup for Python 2.6? Thanks, Abhigyan

2 1

Honoring localedir
by Raúl Núñez de Arenas Coronado 17 Nov '08

17 Nov '08

Hi all :) I would like to support options like "--localedir" in my setup.py, and that means: - 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 "/usr/share/locale", probably. 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 example). 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 googled. - 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 installed. 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 ...

1 0

pypi submission down?
by kiorky 16 Nov '08

16 Nov '08

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? -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF

1 1

patch: solving the two major things that people dislike about setuptools, part 2
by zooko 15 Nov '08

15 Nov '08

Folks: 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?" survey]. These patches make setuptools behave more like distutils in this respect. 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 -- prefix=somedir" and makes setuptools behave more like distutils in this case. --- old-dw-0.6c9/setuptools/command/easy_install.py +++ new-dw-0.6c9/setuptools/command/easy_install.py @@ -249,6 +249,14 @@ instdir = normalize_path(self.install_dir) pth_file = os.path.join(instdir,'easy-install.pth') + # mkdir it if necessary + try: + os.makedirs(instdir) + except OSError: + # Oh well -- hopefully this error simply means that it is already there. + # If not the subsequent write test will identify the problem. + pass + # Is it a configured, PYTHONPATH, implicit, or explicit site dir? 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- capable 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 this regard. --- old-dw-0.6c9/setuptools/command/easy_install.py +++ new-dw-0.6c9/setuptools/command/easy_install.py @@ -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()) + log.warn(self.no_default_version_msg()) if is_site_dir: if self.pth_file is None: @@ -1059,7 +1059,9 @@ http://peak.telecommunity.com/EasyInstall.html#custom- installation-locations -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. +""" % ( self.install_dir, os.environ.get('PYTHONPATH','') ) Regards, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month [1] http://adam.gomaa.us/blog/easy-install-isnt/ [2] https://bugs.launchpad.net/pyopenssl/+bug/238658/comments/25

1 0