Folks:
The allmydata.org tahoe project uses setuptools and the darcs
revision control tool [1].
We've long since written a custom script to generate the version
number from the revision control history. With this we can update
our release version number in exactly one place -- the revision
control tool -- and the script produces the Python module's
__version__ attribute as well as the setup.py's "version" argument.
The script also produces the equivalent of "revision numbers" (which
in darcs is the count of patches that have been applied since the
last release tag).
You can see the details here: [2, 3, 4, 5].
The question is: is there a way to extend setuptools to do something
like this for revision control tools other than svn?
Thank you for your time.
Regards,
Zooko
[1] http://darcs.net
[2] http://allmydata.org/trac/tahoe/browser/misc/make-version.py
[3] http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py
[4] http://allmydata.org/trac/tahoe/browser/setup.py
[5] http://allmydata.org/trac/tahoe/browser/Makefile
Folks:
If you use the darcs revision control tool [1], then you might like
the setuptools darcs plugin [2] that I just wrote, which makes it so
that setuptools by default includes all of your revision-controlled
files in the tarballs it produces. This makes setuptools treat darcs
the same way that it currently treats, I think, svn and cvs.
There are also comparable setuptools plugins for bzr [3] and monotone
[4].
Regards,
Zooko
[1] http://darcs.net
[2] http://pypi.python.org/pypi/setuptools_darcs_plugin
[3] http://pypi.python.org/pypi/setuptoolsbzr
[4] http://pypi.python.org/pypi/setuptools_mtn
Hello there. I'm currently trying to package python bindings for a
library. The bindings are currently compiled in an obscure way, so I end
up with the following
libmylib\__init__.py
libmylib\mylib.pyd
libmylib\dep.dll
mylib.py
Where mylib.py is the SWIG interface for mylib.pyd.
Since I cannot have distutils compile the bindings at all, I'd like to
just install the pyd and dll as "data files" along with the .py in
"site-packages". That can be accomplished with the following:
for scheme in INSTALL_SCHEMES.values():
scheme['data'] = scheme['purelib']
However, bdist_wininst will actually ignore this, at least in python
2.5.1. I'll end up with the pyd and dll in the DATA dir, instead of in
the PURELIB one.
I'm really at loss on how to proceed. I read about forcing /PURELIB/ in
front of file paths with the following:
if sys.argv[1] == 'bdist_wininst':
for fileInfo in COMPILED_LIBS:
fileInfo[0] = '/PURELIB/%s' % fileInfo[0]
However, that doesn't work, and complains the path for each file forced
into PURELIB this way can't be absolute.
I also tried installing the file into an absolute path constructed from
sys.path variables, which actually worked if I ran "setup.py install",
but creating a bdist_wininst with that setup file actually just ignored
the files to copy.
I'm really at loss on how to proceed. The setup file doesn't need to be
cross platform. It just needs to be able to build a friendly windows
installer -- that's all...
If anyone could help, i'd be immensely grateful. Thank you.
--
Alexandre Gauthier
The full version is here:
https://bugs.launchpad.net/zope3/+bug/146373
The short version is that if you run ./setup.py install --single-
version-externally-managed from the zope.interface 3.4.0 source tree,
you'll get everything you need to import zope.interface except for
the "zope/__init__.py" file.
Is this a bug in setuptools?
Regards,
Zooko
I just bundled up and released some zc.buildout recipes I've found
useful. Attached is the README.txt.
http://cheeseshop.python.org/pypi/z3c.recipe.egg
Ross
==============
z3c.recipe.egg
==============
Recipes based on zc.recipe.egg for working with source
distributions.
Editable Distributions
----------------------
The z3c.recipe.egg:editable recipe uses the easy_install --editable
and --build-directory options to download multiple source
distributions.
The source distributions will be placed in the part directory and
managed by the buildout if build-directory is not specified. If so,
the distributions will be replaced when newer versions are available.
So be sure to set build-directory to a directory not managed by
buildout if you want to maintain changes to the source distributions.
The z3c.recipe.egg:editable can be used to assemble a set of
subversion checkouts to work with specifying subversion URLs in
find-links as is supported by easy_install. See the easy_install
documentation for the syntax for using subversion URLs. There are a
number of ways in which it is more flexible to control checkouts via
recipes rather than svn:externals.
Finally, if the develop option is true then the distributions will be
installed in develop mode.
See z3c/recipe/egg/editable.txt for more details.
Running Setup Scripts
---------------------
The z3c.recipe.egg:setup recipe calls arbitrary setup.py commands on
multiple distributions in a buildout.
The z3c.recipe.egg:setup recipe can be used, for example, to automate
releases. When the source is ready for release, the setup recipe is
configured to run the "register sdist bdist_egg upload" setup
commands. To ensure release only runs when intended, the setup recipe
can be used in it's own release.cfg file that extends
the buildout.cfg file. With this setup, releases for multiple
projects can be made with "bin/buildout -c release.cfg".
The z3c.recipe.egg:setup recipe also supports the develop option as
with z3c.recipe.egg:editable.
See z3c/recipe/egg/setup.txt for more details.
Hi,
i hope this is the right mailing-list to ask for help.
Something with my easy install goes wrong:
svcwebkerb:/# easy_install virtualenv -v
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/usr/local/bin/easy_install", line 5, in ?
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
Does anyone have an idea what to do.
I tried update setuptools but with no luck.
Christian
Summary: cannot create windows exe files with distutils and mingw gcc-4.2.
The fix is to remove the def_file from the list of objects in the link line.
When building my own version of py2exe with --compiler=mingw32, I was able
to compile (with some hacking of the py2exe source) but could not create
usable windows binaries. The error I got when trying to run them is,
"myapp.exe is not a valid Win32 application".
Laboriously tracing code and modifying the link line by hand, I found I
could build usable EXEs if I eliminated the following line from
cygwinccompiler.py:
objects.append(def_file)
The def file itself contains:
LIBRARY run.exe
EXPORTS
I'm using the technology preview gcc-4.2.1-dw2 prerelease from the mingw
download site. I don't know if the def file is required on the current
release gcc-3.4.5.
Let me know if this is considered a bug in distutils, or if I need to post
this message to the mingw list.
Thanks in advance
- Paul
--
View this message in context: http://www.nabble.com/mingw32-exe-problem-tf4546042.html#a12972801
Sent from the Python - distutils-sig mailing list archive at Nabble.com.