Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy, and the current plan requires putting some
source code into actual module distributions at the level of some of
the namespace packages.
Example:
toplevel.midlevel
toplevel.midlevel.a
toplevel.midlevel.b
Each of these three is a separate module distribution We want to put
core library code in the midlevel.
Some have warned this is not usually done, but no specific problems
with this approach have been identified. Any guidance on this would be
appreciated.
Thanks!
Hello,
there's a problem with zc.buildout that I can reproduce very easily on
Ubuntu 10.10 (64 bit)
it seems that zc.buildout does not download the dependency from pypi
if the very same version is already available in the host system, but
then for some reason does not add it to sys.path and/or is unable to
use it for some reason; zope.testrunner hence fails on importing
zope.interface
python-zope.interface is installed at version 3.6.1, and
zope.testrunner seems to use that very same dependency.
Any workaround? I'll open an issue on launchpad in the weekend.
Do this in order to reproduce the problem:
# start
cd /tmp
mkdir -p MyProj/myproj
cd MyProj
cat <<EOM > buildout.cfg
[buildout]
parts = test
develop = myproj
[test]
recipe = zc.recipe.testrunner
eggs = myproj
EOM
cat <<EOM > myproj/setup.py
from setuptools import setup
setup(
name="myproj",
version="1.0.0",
description="myproj"
)
EOM
wget http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
python bootstrap.py --distribute && bin/buildout -vvv
bin/test
#end
output from buildout run:
alan@afra:/tmp/MyProj$ python bootstrap.py --distribute && bin/buildout
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
Extracting in /tmp/tmpUAAumj
Now working in /tmp/tmpUAAumj/distribute-0.6.14
Building a Distribute egg in /tmp/tmphpzBsD
/tmp/tmphpzBsD/distribute-0.6.14-py2.6.egg
install_dir /tmp/tmphpzBsD
Creating directory '/tmp/MyProj/bin'.
Creating directory '/tmp/MyProj/parts'.
Creating directory '/tmp/MyProj/eggs'.
Creating directory '/tmp/MyProj/develop-eggs'.
Generated script '/tmp/MyProj/bin/buildout'.
Upgraded:
distribute version 0.6.14;
restarting.
Develop: '/tmp/MyProj/myproj'
install_dir /tmp/MyProj/develop-eggs/tmpoKKOZAbuild
Getting distribution for 'zc.recipe.testrunner'.
install_dir /tmp/MyProj/eggs/tmpQvIfIg
zip_safe flag not set; analyzing archive contents...
Got zc.recipe.testrunner 1.4.0.
Getting distribution for 'z3c.recipe.scripts>=1.0.0'.
install_dir /tmp/MyProj/eggs/tmpQPz2RH
Got z3c.recipe.scripts 1.0.1.
Getting distribution for 'zope.testrunner'.
install_dir /tmp/MyProj/eggs/tmpGvi6JB
package init file 'src/zope/testrunner/testrunner-ex/__init__.py' not
found (or not a regular file)
Creating missing __init__.py for zope.testrunner.testrunner-ex
Got zope.testrunner 4.0.0.
Getting distribution for 'zc.recipe.egg>=1.3.0'.
install_dir /tmp/MyProj/eggs/tmp_pJ4gb
Got zc.recipe.egg 1.3.2.
Getting distribution for 'zope.exceptions'.
install_dir /tmp/MyProj/eggs/tmpxRSjc1
Got zope.exceptions 3.6.1.
Installing test.
Generated script '/tmp/MyProj/bin/test'.
alan@afra:/tmp/MyProj$ bin/test
Traceback (most recent call last):
File "bin/test", line 20, in <module>
import zope.testrunner
File "/tmp/MyProj/eggs/zope.testrunner-4.0.0-py2.6.egg/zope/testrunner/__init__.py",
line 21, in <module>
import zope.testrunner.interfaces
File "/tmp/MyProj/eggs/zope.testrunner-4.0.0-py2.6.egg/zope/testrunner/interfaces.py",
line 21, in <module>
import zope.interface
ImportError: No module named interface
--
Alan Franzoni
--
contact me at public(a)[mysurname].eu
A quick look through the Distribute docs shows that we call the
settings we give to setup py various things. Both "options" and
"arguments" and "parameters" (that last is my fault).
We should probably decide on one thing, and go through the docs to
make sure it's consistent. I prefer "option", although strictly
speaking they *are* keyword arguments.
Opinions?
//Lennart
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Is it possible to tell setuptools to not zip the egg when installing ? I can't
seem to find any option regarding this in the command line help...
Thanks,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJM/0c/AAoJEBdvyODiyJI4EXAH/2EVqqAFIBqmiZLMPyQ6Ibd1
CBLZlT12lm9oQ3+HvGIpow+UlWJCC+IRq/MsbUrrlLk1lSQ1lHt+gnjtiinixi5s
XfH81ykaEhD0biWKVPHamU6LKjzkUl9UVIji3kUcznkl5clhXXuim7sCYfHYUVrH
PyhJgWygK4r7c3bmrpd8VRDPmpRDLb2kFokhNQ+oe3JiX6UGWzVSLG2ohzy7CeDj
AIWdadYc6i5QIHXpra5i8TkX2XLRvtYV5Yb5P3znArjc61Gjd7RRQUm83nug9/xV
ZMsvPE8KtQsbHXKQHQ9npan+YF2p4LJW/4t/7SZw3pY3UHroTFa6Tyb6tXoSjsE=
=GxiC
-----END PGP SIGNATURE-----
At 04:04 PM 12/7/2010 +0530, devyan parmar wrote:
>On Fri, Dec 3, 2010 at 10:14 PM, P.J. Eby
><<mailto:pje@telecommunity.com>pje(a)telecommunity.com> wrote:
>At 04:25 PM 12/3/2010 +0530, devyan parmar wrote:
>Hello,
>
>i am trying to install package from my packageserver using PIP.
>
>for example:
>m trying
>/bin/pip install
>--extra-index-url=<<http://mypkgserver/dev>http://mypkgserver/dev>http://mypkgserver/dev
>package_name==2.4.12b
>
>
>"2.4.12b" is the version of my package but in package server it is
>going as "2.4.12b_1" extra part in version is nothing but a build
>number which getting generated from hudson JOB.
>is setuptool avoids extra build number which goes with my pcakage version ??
>
>
> No. That's why it's not being found. Ask for
> "package_name==2.4.12b-1" instead.
>
>
>Is there any way to avoid the extra hudson build number which is
>coming with my package version ??
Er, don't put it in there?
> coz i need that build number to check which package build test got
> failed...and issue is in package/setup.py i am specifying only
> versions of dependent package.
Don't use '==', then, use '>='.
>and pip install is looking for only those particular version package
>in package server, but finds hudson build number attached with
>package version which is mismatching with setup.py install requires .
>
>can you help me how version is getting identified from the package
>by setuptools.??
>
>Thanks Regards
>devyan parmar
Hello,
I'm trying to figure out how to produce a Windows installer for
pure-Python packages such that it will "just run" on a 64-bit Windows
platform.
I'm running a 32-bit Windows (Windows 7 Pro), and the msi produced by
python setup.py bdist_msi
works just fine on Win 7 Pro. I don't have a win64 platform to test on.
The distutils docs for Python 2.7.1 say: ""In most cases, the bdist_msi
installer is a better choice than the bdist_wininst installer, because it
provides better support for Win64 platforms, allows administrators to
perform non-interactive installations, and allows installation through
group policies.""" but give no more detail.
Running
python setup.py bdist_msi --help
produces only one item of interest:
Options for 'bdist_msi' command:
--plat-name (-p) platform name to embed in generated filenames
(default: win32)
Does the win32 version work on win64? Is the purpose of changing the name
solely in order that win64 users are not deterred from using it because
the name includes "win32"?
Cheers,
John
At 04:25 PM 12/3/2010 +0530, devyan parmar wrote:
>Hello,
>
>i am trying to install package from my packageserver using PIP.
>
>for example:
>m trying
>/bin/pip install
>--extra-index-url=<http://mypkgserver/dev>http://mypkgserver/dev
>package_name==2.4.12b
>
>"2.4.12b" is the version of my package but in package server it is
>going as "2.4.12b_1" extra part in version is nothing but a build
>number which getting generated from hudson JOB.
>is setuptool avoids extra build number which goes with my pcakage version ??
No. That's why it's not being found. Ask for
"package_name==2.4.12b-1" instead.
I installed the 0.39 version of python-sybase using easy_install -m. That
worked fine, but that version is extremely old. Is there a way to use
easy_install with the a checkout from the project's version control system?
I see this in the help output:
--local-snapshots-ok (-l) allow building eggs from local checkouts
but how do I specify the location of the local checkout?
Thanks,
--
Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/
At 03:14 PM 12/3/2010 +0100, Alan Franzoni wrote:
>Hello,
>I've got some issues with dependency specification; this seems to
>apply both to setuptools and distribute.
>
>Let's suppose I want to have a dependency on a certain library
>major.minor , because I want to depend on a certain API - which is
>supposed to be stable for that lib unless at least the minor changes -
>but I want to pick in any bugfix release they might end up with.
>
>I'd like to do something like "pick up the latest 1.1 release of mylib"
>
>The only way to do it seems to be this:
>
>install_requires = [ "mylib>=1.1, <1.1.999" ]
>
>if I use just == 1.1 , it picks 1.1.0 . If I use >= 1.1 and <1.2.0, it
>will pick beta releases for 1.2 as well.
Use ">=1.1,<1.2dev".
Hello,
I've got some issues with dependency specification; this seems to
apply both to setuptools and distribute.
Let's suppose I want to have a dependency on a certain library
major.minor , because I want to depend on a certain API - which is
supposed to be stable for that lib unless at least the minor changes -
but I want to pick in any bugfix release they might end up with.
I'd like to do something like "pick up the latest 1.1 release of mylib"
The only way to do it seems to be this:
install_requires = [ "mylib>=1.1, <1.1.999" ]
if I use just == 1.1 , it picks 1.1.0 . If I use >= 1.1 and <1.2.0, it
will pick beta releases for 1.2 as well.
That's quite clumsy, since it's something I do often and it's quite a
common practice (I suppose); isn't there any regex/wildcald character
support? Would any patch about that be accepted?
--
Alan Franzoni
--
contact me at public(a)[mysurname].eu
