Distutils-SIG February 2010

distutils-sig@python.org

45 participants
58 discussions

Start a nNew thread

dependencies
by Assem Chelli 19 Feb '10

19 Feb '10

Hi, how can i add the dependencies of my project in setup.py ,

1 0

Changing bdist_rpm locations to conform to other rpm packaging
by Stanley A. Klein 15 Feb '10

15 Feb '10

I'm trying to build rpms for some Python packages located in an svn repository. I would prefer to use the same locations for builds and results as for non-Python rpm packages. I can set --rpm-base=$HOME/rpmbuild and some of the process happens in subdirectories of rpmbuild, but in the end, the source rpms are moved from rpmbuild/SRPMS to a dist directory under the package home, the binary rpms are moved from rpmbuild/RPMS to the same directory, and the tar.gz are similarly moved. I would prefer to have everything created as part of the build remain in the rpmbuild directory. How can I prevent files from being stored back in the svn repository as a result of the package build? Stan Klein

1 0

Buildout: How to include installed packages in sys.path?
by Gustavo Narea 15 Feb '10

15 Feb '10

Hello. I've written a Buildout recipe which relies on a function defined in a package whose name is set in the recipe's options. That package must have already been installed. According to the documentation, I should use zc.buildout.easy_install:install() like this: install(["mydistribution"], None) But if I use None, I get an exception because Buildout tries to use .startswith() with None. Then, if instead of None, I use buildout['buildout']['directory'], it tries to install the distribution pulling all its dependencies (ignoring the fact I set a download cache in ~/.buildout/default.cfg). I just want to make a package available in sys.path. How should I do that from a Buildout recipe? Note I really just want to add it sys.path, not get the actual function/module, because it's going to be used by a function called from my recipe, not by my recipe. The following code illustrates how the recipe will look like: ==== class MyRecipe(object): def __init__(self, buildout, name, options): self.the_package = options['package'] def install(self): add_to_sys_path(self.the_package) do_something_useful(self.the_package) return () ==== I'm using zc.buildout 1.4.3. Thanks in advance. -- Gustavo Narea. Software Developer. 2degrees, Ltd. <http://www.2degreesnetwork.com/>.

2 4

Attaching changelog
by Michał Klich 14 Feb '10

14 Feb '10

Hi, I am trying to attach changelog to spec file using --changelog= as a parameter. My changelog test file has lines starting with (*) but i keep getting error: %changelog entries must start with * when building rpm. Is it a right way to add changelog to spec file? Thank you for your help -- Michał Klich klich.michal(a)gmail.com michal(a)michalklich.com http://www.michalklich.com

1 0

setup.py#package_data - howto include entire folder when installing
by Aljoša Mohorović 12 Feb '10

12 Feb '10

i've created MANIFEST.in and setup.py and when i call "python setup.py sdist" archive is created normally and archive contains all files. when i call "python setup.py install" data files are not installed and i have no idea why. i've been searching for a solution but every combination i've tried failed. i usually have only html templates so something like: package_data = {'mypkg': ['templates/*.html',]} works as expected but now i have a folder with different types of files and nested folder structure. my question is: - how can i define in setup.py to include folder (let's call it "data") and everything in data so that when "python setup.py install" is called that folder is copied with python code? something like "package_data={'mypkg': ['data/*']},"? Aljosa Mohorovic

2 2

Distributing __only__ *.pyc
by Torsten Mohr 11 Feb '10

11 Feb '10

Hi, not sure if this is possible, i'd like to distribute a pure python module as .pyc because there is some code in there that idon't want to spread yet. I plan to release the code as open source later, but it is not possible for now. I know that something like disassembling is possible but for i don't expect that somebody will take that effort. Is it possible to distribute a module.pyc using distutils? How would that setup script look like? Thanks for any hints, Torsten.

5 5

Distributing (complicated) C extensions
by James Porter 11 Feb '10

11 Feb '10

Before I get started with the meat of this message (it's pretty long - for me, anyway), I should give a brief overview. I'm developing Python bindings for a set of interfaces called ITAPS, which contains a few independent libraries. If you want to look at my setup.py file (it's pretty scary), you can download the source at <http://pypi.python.org/pypi/PyTAPS/0.9.1>. Basically, I have three somewhat-related questions, which I wrote a big pile of words about below. The short version is: * Are multiple distributions inherently better/saner than one distribution with a handful of optional features? * What's the best way to detect whether libraries exist to turn said features on/off? * How do I install header files when using setuptools (or easy_install)? Ok, now for the long version: First, this distribution is fairly complicated, with a handful of setuptools Features controlling the various libraries I want to work with. I've waffled on whether this should be one distribution or several, but the former is a little problematic because the "core" module doesn't actually correlate to an independent thing on the C side. It really just piggybacks on each of the libraries. So basically there's no reason for the "core" module to exist in isolation, and it would actually be impossible to compile unless one of the "real" libraries was present. Is rolling this all together a terrible idea? Or a good one? Second, having a single distribution with multiple features that can be enabled/disabled obviously requires a bit of work for configuration. Right now, it tries to detect if each library is installed, and if not, it disables that feature automatically. I mostly do this to make easy_install "just work" even if you don't have everything. I should explain how I do configuration now: each library has a Makefile fragment that defines useful variables, e.g. $MYLIB_INCLUDEDIRS, that I read in and add into the appropriate places in the Extension. Each of my Features has a global --feature-path option that lets you point to the Makefile fragment. If you don't specify that, it steps through some environment variables and tries to find it. If it still can't find it, it'll assume you specified all the stuff you need as options to build_ext. Then I try to compile a simple file with the necessary header to make sure I got the paths right. All of this work is done in an overrided version of build_ext (grabbing the Makefile fragment happens during finalize_options and the compilation test happens during run). This seems pretty hacky to me, especially since there's a config command in distutils that does some of what I want. However, I'm not sure how to actually *use* this. I assume I override the command, but what would it look like from a user's perspective? How do I connect it up to the build process? Finally, I'd like to be able to install header files from my distribution. Looking through the distutils docs, there's an install_headers command that gets run as a part of install, and I can just specify headers=['foo.h'] as an option to setup. However, this doesn't seem to work with setuptools/distribute; it looks like they hijack the install command and, instead of actually running it directly, they manually run install_lib, install_data, etc. This is made worse by the fact that, even if I stuck with vanilla distutils, easy_install appears to inject its version of Distribution into my setup.py anyway. (There's a way to work around that, but it's really messy. Think yanking the distutils.core Distribution class - "_Distribution" in the code - out of setuptools.dist. Barf.) If you got all the way here, thanks for reading! Hopefully someone with a little more experience than me in this can give me a few pointers. - Jim

1 0

PEP 376 - RECORD file / Data files + pip feedback ?
by Tarek Ziadé 10 Feb '10

10 Feb '10

Hi, The part that still requires some work is how to handle files prefixes in the RECORD file. Last time we said that we could benefit of having a PREFIXES file. Then Wolojda started to work on a much more complete solution to track data file locations : http://mail.python.org/pipermail/distutils-sig/2009-November/014424.html But IIRC he's not able to work on this at this time. (CCing him in case..) What I suggest is that we leave this new work for a future enhanced version of PEP 376, and try to finish a version that we would want to have in Python 2.7 (that's coming very soon), where RECORD contains what we want to make it possible to remove installed files + provide the query API. As far as I am concerned, the RECORD thingie needs more live examples on various platforms (that's what I am working on now), But since Pip has now a uninstaller for a few months, the question is: what do you Pip guys think about this RECORD file ? (cc'ing Ian as well - I know the other involved in that are listening here :)) Regards Tarek -- Tarek Ziadé | http://ziade.org

8 17

Building a platform-independent dist?
by skip＠pobox.com 10 Feb '10

10 Feb '10

It's been several months since I created a distribution using the bdist command. Now I can't seem to build a simple gztar distribution. My MANIFEST.in looks like this: include README RELEASE-NOTES LICENSE MANIFEST include lockfile.py setup.py ACKS recursive-include doc *.rst conf.py Makefile MANIFEST is: ACKS LICENSE MANIFEST README RELEASE-NOTES lockfile.py setup.py doc/glossary.rst doc/index.rst doc/lockfile.rst and I'm executing python setup.py bdist --formats=gztar (where python is 2.7a2+). The output is a .tar.gz file but it includes ".macosx-10.4-i386" in the filename and the tar file itself has more structure and fewer files than I think it should have: % tar tfz dist/lockfile-0.8.macosx-10.4-i386.tar.gz ./ ./Users/ ./Users/skip/ ./Users/skip/local/ ./Users/skip/local/lib/ ./Users/skip/local/lib/python2.7/ ./Users/skip/local/lib/python2.7/site-packages/ ./Users/skip/local/lib/python2.7/site-packages/lockfile-0.8-py2.7.egg-info ./Users/skip/local/lib/python2.7/site-packages/lockfile.py ./Users/skip/local/lib/python2.7/site-packages/lockfile.pyc setup.py is simple: from distutils.core import setup setup(name='lockfile', ... bunch of kwd args elided ... ) Where are the missing files? How do I create a platform-independent distribution? -- Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/

3 5

Fwd: PEP 345 and PEP 386
by Tarek Ziadé 10 Feb '10

10 Feb '10

FYI, PEP 345 and 386 are now accepted. Thanks to all the people that helped in building them ! ---------- Forwarded message ---------- From: Guido van Rossum <guido(a)python.org> Date: Wed, Feb 10, 2010 at 12:29 AM Subject: Re: PEP 345 and PEP 386 To: Tarek Ziadé <ziade.tarek(a)gmail.com> Cc: Python-Dev <python-dev(a)python.org> On Thu, Feb 4, 2010 at 2:55 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum <guido(a)python.org> wrote: > [..] >> I have one comment on PEP 345: Why is author-email mandatory? I'm sure >> there are plenty of cases where either the author doesn't want their >> email address published, or their last know email address is no longer >> valid. (Tarek responded off-line that it isn't all that mandatory; I >> propose to say so in the PEP.) > > Yes, I propose to remove the mandatory flag from that field. Since this is done I now approve both PEP 345 and PEP 386 (which is not to say that small editorial changes to the text couldn't be made). -- --Guido van Rossum (python.org/~guido) -- Tarek Ziadé | http://ziade.org

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG February 2010