Mailman 3 April 2010 - Distutils-SIG

tag-build vs tag_build in egg_info
by Jason Baker 20 Apr '10

20 Apr '10

The way my project is set up right now, we have a setup.cfg that specifies .dev for tag_build. This way, we can have the file tagged properly when developing from source. We also have a Hudson CI server that will run the tests and then generate an sdist with the build number added (using the command "python setup.py egg_info -b dev-$BUILD_NUMBER sdist"). Now, suppose I use the following setup.cfg in my project: [egg_info] tag_build=.dev If I run the following commands, everything works as expected: $ python setup.py egg_info -b .dev-123 $ tar -xzvf dist/jiva_interface-3.0.1.dev-123.tar.gz $ cat jiva_interface-3.0.1.dev-123/setup.cfg [egg_info] tag_build = .dev-123 tag_date = 0 tag_svn_revision = 0 This is the appropriate behavior: I want the tag_build option to be overridden in the resulting setup.cfg file. However, I made a mistake and used tag-build instead of tag_build: [egg_info] tag-build=.dev If I run the same commands as above, the sdist is named the same, the egg_info version is the same, but the setup.cfg is different: $ python setup.py egg_info -b .dev-123 $ tar -xzvf dist/jiva_interface-3.0.1.dev-123.tar.gz $ cat jiva_interface-3.0.1.dev-123/setup.cfg [egg_info] tag_build = .dev-123 tag_date = 0 tag_svn_revision = 0 tag-build = .dev As you can see, it's creating both a tag-build and tag_build option. And it's going by the tag-build option, which isn't what I want. Is this a bug, or is there some kind of subtlety to this option that I don't know about?

1 0

bdist dist-dir
by Ernesto Posse 17 Apr '10

17 Apr '10

Hi. I have a couple of questions regarding the installation directory when using binary distributions. When I do python setup.py bdist the generated gztar ball contains the files prefixed with the directory where they will be unpacked, which in my machine is "./usr/local/lib/python2.6/dist-packages", which is fine if the user has the same version of Python installed in the same directory as I do, but in general this is not the case. So my questions are: 1) why is this the behaviour of bdist? 2) is there a way to specify "install wherever the user has Python installed" with binary distros? the --relative option still seems to assume certain prefixes. 3) if I used sdist instead, running python setup.py install would install in the right place, but I want to distribute pre-compiled C extensions. What is the most appropriate way of doing this? a bdist seems the most natural, but it seems to assume certain target directories. I suppose one could do an sdist and include the compiled extensions as "data files" but that seems like a hack against the "spirit" of distutils. 4) there is a build_rpm command. Why isn't there a build_deb? and are there any plans to add this? Thanks. -- Ernesto Posse Applied Formal Methods Group - Software Technology Lab School of Computing Queen's University - Kingston, Ontario, Canada

1 0

Re: [Distutils] Passing user and password to easy_install
by Simon de Vlieger 16 Apr '10

16 Apr '10

Luigi, I am not sure if using PyPi for private package distribution (what this equates to) would be a particularly nice idea. This way the PyPi would contain packages which cannot be installed by users of PyPi. Alas, I don't know of any ways distutils can fulfill your request in its current form. Regards, Simon de Vlieger On 7 apr 2010, at 17:46, Luigi wrote: > Dear All, > > I'm using setuptool module to pack my software and I'd like to > distribute it via PyPI, making it installable exploiting easy_install. > > I have a requirement, though, that I'm not sure is supported by > setuptools: > > My software must be distributed to registered/authenticated/authorized > users only. > > Well, registering the packages I might specify that the download URL > is a CGI, optionally with Basic Authentication accepting a default > user and password as described here: > > http://peak.telecommunity.com/DevCenter/EasyInstall#id17 > > This would provides me with the possibility of tracking the number of > downloads, but always with a single public user/password. But I need > to know who is downloading my packages. > > Is there a way to associate a user and password to easy_install > command? Such data would be nice if passed as Basic Authentication > data to the download URL... > > Thanks in advance. > > Luigi > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig

5 5

zc.buildout and "Not upgrading because not running a local buildout command"
by Adam GROSZER 15 Apr '10

15 Apr '10

Hello, Having problems here with the above. The thing is that there should be two projects installed on the same server, but the one is a zope KGS 3.4 the other is a ztk/bluebream-ish. The two have different version requirements for setuptools and zc.buildout. The buildout.cfg comes from the web like this: buildout -t 2 -c http://mypypi.org/++projects++/proj/proj-stage-0.0.4.cfg (On top of that this is driven by keas.build, but that should not matter) Buildout (1.4.1) is installed via easy_install and setuptools (0.6c9). Therefore the message "Not upgrading because not running a local buildout command". The message is reasonable, but still makes problems in the way of making the one of the projects non-installable. Would not it be easy to create a bin/buildout script and restart with that? Or is there any other sane solution for this (that I missed)? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Before Xerox, five carbons were the maximum extension of anybody's ego.

2 4

[issue106] Confusing docs on PiPI
by Dave Abrahams 10 Apr '10

10 Apr '10

New submission from Dave Abrahams <dave(a)boostpro.com>: At http://pypi.python.org/pypi/setuptools "Install setuptools using the provided .exe installer" is confounding. Unt il you scroll to the bottom of the page you have no clue where this .exe is "provided," and surprisingly there's no link in the opening paragraph! ---------- messages: 510 nosy: dabrahams priority: bug status: unread title: Confusing docs on PiPI _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue106> _______________________________________________

1 0

Fwd: [PythonInfo Wiki] Update of "SiteImprovements" by 97.86.230.99
by anatoly techtonik 10 Apr '10

10 Apr '10

This is probably for you to consider. -- anatoly t. ---------- Forwarded message ---------- From: python.org wiki <wiki(a)python.org> Date: Sat, Apr 10, 2010 at 5:48 PM Subject: [PythonInfo Wiki] Update of "SiteImprovements" by 97.86.230.99 To: "python.org wiki" <wiki(a)python.org> Dear Wiki user, You have subscribed to a wiki page or wiki category on "PythonInfo Wiki" for change notification. The "SiteImprovements" page has been changed by 97.86.230.99: http://wiki.python.org/moin/SiteImprovements?action=diff&rev1=54&rev2=55 == misc == + * Explain how to use .egg package archives. As a new user, I am unable to find anything, but I do find .egg files in the package index. * Merge '''pydotorg-www''' and '''pydotorg-redesign''' lists into one http://mail.python.org/pipermail/pydotorg-www/2010-February/000082.html * Fix webmaster(a)python.org response bug (per Issue:7929)

1 0

Tentative release schedule for distutils2
by Tarek Ziadé 08 Apr '10

08 Apr '10

Hello, FYI, here's a tentative release schedule for Distutils2 1.0a1 - 2010-04-30 (Python 2.7b2) 1.0a2 - 2010-05-28 (Python 2.7rc1 and GSOC starts) 1.0b1 - 2010-06-25 (Python 2.7 final) 1.0b2 - 2010-07-17 (GSOC Mid-term) 1.0c1 - 2010-08-30 (GSOC Ends) 1.0 final - 2010-09-15 We will probably have new releases after 1.0 quite quickly, depending on the feedback Regards Tarek -- Tarek Ziadé | http://ziade.org

1 0

How to separate dependencies for using my package vs developing my package?
by Matthew Wilson 08 Apr '10

08 Apr '10

I'm working on a package with two kinds of dependencies. My package needs jinja2 and docutils to generate output. Then I use nose, sphinx, mock, and a bunch of other testing tools while I'm writing code for my package. I don't see users of the app needing to run the test code, but maybe they might want to generate the docs. In pip, easy_install, whatever, is there some recommended way of describing these separate kinds of dependencies? Matt

2 1

Re: [Distutils] modules in sub-packages
by P.J. Eby 07 Apr '10

07 Apr '10

At 11:00 PM 4/7/2010 +0530, Amit Sethi wrote: >I am trying to create a module for the docutils . I wish to install >it docutils.writer.something Is that a documented, official way to extend docutils? If not, and docutils.writer is not a namespace package, then you should not be doing that. >I have docutils installed at >/usr/local/lib/python2.6/dist-packages/docutils-0.6-py2.6.egg >on my ubuntu machine but when I tried to install it create a seperate >package called docutils and saves >the package in that ? How do I tell a package that this particular >package is a subpackage of a library >the setup.py of the package looks like : > license='Public Domain', > packages=['docutils.writers'], > package_dir={'docutils.writers':'docbook'}, > scripts=['rst2docbook.py'] The correct way to do this is to NOT list packages or package_dir; just use py_modules = 'docutils.writer.docbook', and have a docutils/writer/docbook.py file. This will install it in a distutils-compatible way, but not a distribute-compatible or setuptools-compatible way. Really, this is not a well-supported scenario in any case -- it is to be avoided if at all possible. Installing your code into other people's packages is a bad way to extend them. (Setuptools and Distribute offer better ways of providing extensibility, such as namespace packages and entry points.)

1 0

modules in sub-packages
by Amit Sethi 07 Apr '10

07 Apr '10

I am trying to create a module for the docutils . I wish to install it docutils.writer.something I have docutils installed at /usr/local/lib/python2.6/dist-packages/docutils-0.6-py2.6.egg on my ubuntu machine but when I tried to install it create a seperate package called docutils and saves the package in that ? How do I tell a package that this particular package is a subpackage of a library the setup.py of the package looks like : license='Public Domain', packages=['docutils.writers'], package_dir={'docutils.writers':'docbook'}, scripts=['rst2docbook.py'] -- A-M-I-T S|S

1 0