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
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/>.
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
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
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.
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
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
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/
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