I have a project I want to use with the 'use2to3' option of distribute to maintain a common codebase for both 2.x and 3.x..
(First of all, let me say thank you so much for adding this option to distribute.. it makes this sort of thing so much easier :) )
Anyway, everything works fine for the code in the package directory. The problem, however, is that I also have some directories containing unit tests, etc, which are not under the source dir (since I don't want them to be distributed), but do still need to be converted with 2to3 before they can be used (i.e. when doing 'python3 setup.py test')
I poked around a bit and didn't see an obvious way to do this. Can anybody suggest the best way to go about implementing it?
At 06:26 AM 8/25/2010 +0200, Attila OlÃ¡h wrote:
>I know it doesn't make sense to put a password on the site that hosts
>distribute/setuptools, but we have a private PyPI and we'd like to use
>that as --download-base too.
The goal of ez_setup is to be small, so every feature added is a
tradeoff. In this particular case, it seems like the simplest fix is
to pass the URL of a non-password-protected setuptools to ez_setup,
and then use your password-protected PyPI afterwards.
I got zc.recipe.testrunner tests pass.
Now after I added zc.recipe.testrunner 1.2.1 to ZTK trunk, I have the
following problems after running
"bin\buildout -t 2 -c development.cfg":
(This is MS windows!)
could't load zc.buildout entry point default
Picked: zope.testing = 3.9.5.
Getting section test-ztk.
Initializing section test-ztk.
Installing recipe z3c.recipe.compattest.
Getting distribution for 'zope.testing>=3.6.0,<3.10.0'.
Error: Picked: zope.testing = 3.9.5
Complete output is here:
Source is here:
What's going on?
buildout has "allow-picked-versions = false" and "zope.testing =
3.9.5" so why "Error: Picked: zope.testing = 3.9.5" ???
Adam GROSZER mailto:email@example.com
Quote of the day:
We find freedom when we find God; we lose it when we lose Him.
- Paul E. Scherer
Is it possible to force bootstrap.py to download the setuptools or
distribute egg even though it can be found on the system? Not
downloading a fresh copy will cause issues in some edge cases, for
example take the following situation:
Say my site-packages are located in /usr/lib/python2.6/site-packages/.
Then, I set my PYTHONPATH to contain
/usr/local/lib/python2.6/site-packages/ (note *local*).
Then, I install distribute or setuptools into
Then, I install a third party package, say lxml, also to
Then, in my project, I run python bootstrap.py (with or without the
--distribute flag, depending on which package I have in
Then, bootstrap.py will not download a fresh copy, instead it will add
/usr/local/lib/python2.6/site-packages/ to sys.path so that it can use
the existing one.
Then, say I have the following buildout.cfg:
develop = .
include-site-packages = false
I would now expect buildout to not include lxml from my PYTHONPATH,
but build it instead and put it in my eggs-dir. However, it's not the
case: adding /usr/local/lib/python2.6/site-packages/ to sys.path will
make lxml available so buildout will not build it.
My question is, how can I force buildout to build its own lxml, or
better yet, force it to download a fresh setuptools or distribute egg,
avoiding adding extra stuff to sys.path, thus making unnecessary
system packages available and, thus, not putting them in the eggs-dir.
Note, this is zc.buildout 1.5.0. I hope I gave enough details.
Here's my traceback:
$ python bootstrap.py --distribute
Traceback (most recent call last):
File "bootstrap.py", line 171, in <module>
File "<string>", line 145, in use_setuptools
File "<string>", line 124, in _do_download
File "<string>", line 193, in download_setuptools
File "/usr/lib64/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib64/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/lib64/python2.6/urllib2.py", line 409, in _open
File "/usr/lib64/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib64/python2.6/urllib2.py", line 1178, in https_open
return self.do_open(httplib.HTTPSConnection, req)
File "/usr/lib64/python2.6/urllib2.py", line 1116, in do_open
h = http_class(host, timeout=req.timeout) # will parse host:port
File "/usr/lib64/python2.6/httplib.py", line 1105, in __init__
HTTPConnection.__init__(self, host, port, strict, timeout)
File "/usr/lib64/python2.6/httplib.py", line 661, in __init__
File "/usr/lib64/python2.6/httplib.py", line 686, in _set_hostport
raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
httplib.InvalidURL: nonnumeric port: 'password(a)pypi.example.com'
Since URLs like
seem to be handled well by *urllib*, but not by *urllib2*, I wonder
why are they handled by urllib2 instead of urllib.
I know it doesn't make sense to put a password on the site that hosts
distribute/setuptools, but we have a private PyPI and we'd like to use
that as --download-base too.
New submission from AndiDog <AndiDog(a)web.de>:
This is a follow up to the following problem:
If I create a MSI installer from a Python package with a computer that has its Python installation in 'C:\Program Files\Python26', and install it on another computer that has it installed in 'C:\Python26', for example, the shebang (for a script in gui_scripts) will still be #!"C:\Program Files\Python26\pythonw.exe"
With bdist_wininst installers, this problem does not occur because the code makes a distinction for them:
executable = "python.exe"
executable = nt_quote_arg(executable)
In case of a MSI installer, wininst is False and the full absolute path of pythonw.exe is inserted. I can't understand why an absolute path should be necessary. Using a #!pythonw.exe shebang line works even if the matching Python installation is not in the PATH or an incompatible Python version is in the PATH. So I propose to change that first line to
if wininst or sys.platform == "win32":
title: Shebang for gui_scripts on Windows should be #!pythonw.exe for MSI installers, too
Setuptools tracker <setuptools(a)bugs.python.org>
I have here this version spec in setup.py:
but zc.buildout does not get it right.
Source is here:
Output is here:
Why on earth does zc.buildout pick zope.testing = 3.10.0 with the
Adam GROSZER mailto:firstname.lastname@example.org
Quote of the day:
There is no true and abiding morality that is not founded in religion.
- Henry Ward Beecher
I use the 'develop' command instead of 'install' as it does not copy the source files to site-packages, and I can continue developing on the working copy .. thanks to .egg-link. My project also has 'extras' dependencies. Is there a way to get these dependencies installing automatically with the develop command?
None of the options that 'setup.py develop' takes seem to be applicable to the extra dependencies.
On 21.08.2010 17:43, P.J. Eby wrote:
> You need either a revision control system, or a MANIFEST.in file (see
> distutils docs regarding MANIFEST.in).
And that was the key... I didn't have the MANIFEST.in file. Adding
'recursive-include test *.py' solved the problem. Packages reuploaded
and I'm happy :)
I'm trying to package tests file in the sdist only and it doesn't really
If I do:
packages = find_packages(exclude=['tests']),
test_suite = "tests",
this doesn't package tests anywhere. Using either general find_packages
includes tests in both sdist and bdist.
How can I resolve this? Essentially I want either tests.py, or
tests/__init__.py to be distributed in sdist, but not in bdist.