Hi folks,
Is there a way to build multiple eggs within the same project? I'm using
distutils with buildout which makes certain assumptions about setup.py
being able to build a single egg. So, I started looking around and found
python-repoze.who-plugins which has a setup.py in the base of the project
calling upon individual setup.py files in subdirectories. I'm not sure
this is recommended though and not sure how it would work with buildout
either. So, I'm wondering if there might be a reasonable example of a
project building multiple eggs from the same project.
--
Marc Tardif <marc.tardif(a)canonical.com>
Freenode: cr3, Jabber: cr3(a)jabber.org
1024D/72679CAD 09A9 D871 F7C4 A18F AC08 674D 2B73 740C 7267 9CAD
I have a package with a source that looks like this:
setup.py
MANIFEST.in
Prototype/libraries/jquery.js
Prototype/style/main.css
my/
my/package/
my/package/templates/libraries -> ../../../Prototype/libraries
my/package/templates/style -> ../../../Prototype/style
what I would like to accomplish is that when a bdist is made either
Prototype/ is installed somewhere and the symlinks point to it, or the
symlinks are replaced with a copy of the data they point to.
For a package maintained in subverion this works: when the sdist is
created the symlink is replaced with a copy of the thing it points to,
which is then included in the bdist. For a package maintained in git
this does not work: the symlink always appears to be ignored. Is there
a way to accomplish this?
Wichert.
--
Wichert Akkerman <wichert(a)wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Hello
I'm new to Buildout and need to figure out how to accomplish a (seemingly)
simple usecase: Install my project from source into an isolated environment.
My project has a Distribute-based setup.py and I'd like to install it and
its dependencies to an isolated environment. I gather this should be doable
using Buildout, but how? I've experimented a bit and read the documentation
on PyPi, but so far I have not succeeded.
Thanks!
Arve
Hi
I've got buildout (1.5.2) working for me, but it emits some errors when
installing my distribution (under Python 2.7 on Windows).
$ .\bin\buildout.exe -v -v -v
Installing 'zc.buildout', 'distribute'.
Download error: [Errno 11004] getaddrinfo failed -- Some packages may not be
found!
The same problem does *not* occur on Linux, I've found. Is this due to a bug
in buildout?
Thanks,
Arve
New submission from Mike Cowperthwaite <mcow(a)well.com>:
This may be specific to Windows Vista and Windows 7, I think. I am using 64-bit Windows 7; see also this page for similar problem with Vista:
http://catherinedevlin.blogspot.com/2009/08/workaround-easyinstall-windows-…
It seems that Windows forces easy_install (and pip) to open into a new cmd shell, when run from a command shell. When the install program completes, the cmd shell closes. If there are any problems with the install, the program errors are lost, making troubleshooting difficult.
The hack of elevating to Administrator described there as working under Vista doesn't work for me on W7/64.
I don't expect anyone to figure out how to keep Windows from launching into a new window, but, as a workaround: I'd like a command-line switch I can add to easy_install which would pause at the end of the install and print something like "Hit any key to continue" and then wait for that activity.
----------
messages: 613
nosy: mcow
priority: wish
status: unread
title: Windows: easy_install's 'DOS' window closes automatically, error msgs lost
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue126>
_______________________________________________
Hello all,
A member of the Tahoe-LAFS community was kind enough to build a Python
2.6 amd64 MSI installer for pyOpenSSL 0.12 for me (since I am not set up
to build anything for 64 bit Windows).
The MSI is available at http://twistedmatrix.com/~exarkun/pyOpenSSL-0.12
.win-amd64-py2.6.msi for the time being. It might be interesting to
inspect in considering the question I have.
First I tried uploading it to PyPI using the web interface.
Unfortunately this resulted in a failed upload (several times) because
"invalid distribution file".
Then I tried using the distutils upload command (which I had to modify
to allow uploading a file which was already built, rather than one which
was being built at the moment). This produced the same result ("Upload
failed (400): invalid distribution file").
So... is this a distutils bug? Is there something wrong with the MSI?
Is it something wrong with pyOpenSSL's setup.py? Is it a bug in PyPI
causing it to reject a valid MSI?
(I hope the cross-posting is okay, since this topic seems to straddle
these two areas.)
Thanks,
Jean-Paul
Hi,
I want to build binary wininst distributions of pure python package on
unix. That's pretty possible and works already. But I need to patch
`install_lib` and `install_data` targets with custom platform-specific
modifications. I've noticed that bdist_wininst runs `install_*`
targets during the build. The question is:
How can `install_lib` detect if it is executed to build code for
windows platform when it is executed on unix?
Please, CC.
--
anatoly t.
Hello,
Perhaps *packages.python.org* will become the new go-to place where people
expect to find documentation, like PyPI. I prefer to host my docs on my own
server. Can I set something in my project settings that would cause a
redirect to be created from `packages.python.org/my_project` to my own doc
site?
Thanks,
Ram.
Re-posting for visibility:
http://groups.google.com/group/the-fellowship-of-the-packaging/browse_threa…
While working on the new pysetup commands I ran into some issues when
trying to uninstall projects based on distribute/setuptools. The
current install method used in packaging is to "shell" out and call:
# projects based on distutils
python setup.py install --record=/path/to/record_file
# projects based on setuptools
python setup.py install --record=/path/to/record_file
--single-version-externally-managed"
This works and gets the project installed. However, this does not give
us PEP 376 compatibility and adds a dependency on
distribute/setuptools. Another side effect from the methods above, the
RECORD file does not end up in the right place. I am sure we can fix
this, but do we really want to?
To get everything working it seems we will have to do a custom
distribute/setuptools install similar to how pip does things.
https://github.com/pypa/pip/blob/master/pip/req.py#L540
Note, we do not have the above issue with packaging (setup.cfg) based projects.
At this point it seems we need to pick one of three options:
1. Only support packaging based projects (setup.cfg)
2. Only support packaging and distutils based projects, punt on
projects that require distribute/setuptools.
3. Support all three, packaging, distutils, and distribute/setuptool
based projects.
Pros and Cons
=============
Option 1
--------
Only support packaging based projects(setup.cfg).
Pros
* enforce the new standard, setup.cfg and static metadata.
* clear project scope; one way forward
* no dependencies on 3rd party modules (distribute)
* chance to make a clean break; distutils is still in the stdlib and
pip supports Python 3
Cons
* unable to install most projects day one; will have to defer to 3rd
party tools such as pip and distribute
Option 2
--------
Only support installing packaging and distutils based projects and
punt on projects that require distribute/setuptools.
Pros
* can install more projects than option 1.
* no dependencies on 3rd party modules (distribute)
* promote the new standard with a transition for distutils based projects
Cons
* still supports setup.py
* causes confusion; can install some projects with a setup.py and not others
* may prolong the move to setup.cfg and static metadata
* miss our chance for a clean break
Option 3
--------
Support all three, packaging, distutils, and distribute/setuptools
based projects.
Pros
* can install more projects than option 1 and option 2
Cons
* WILL prolong the move to setup.cfg and static metadata. Most people
will continue to use what they know best.
* miss our chance for a clean break
I am leaning toward Option 1 myself, as option 2 will only cause
confusion. Option 3 seems like going backward by requiring distribute
and will prolong the move to setup.cfg and static metadata. Going with
option 1 will require a lot of effort to get the community on board
and start converting to a valid setup.cfg, or providing support for
both, a valid setup.cfg and setup.py.
With packaging and pysetup being new tools we should keep them clean
and focused on the future. This is especially true when good
alternatives exist to provide a transition strategy for most projects.
Thoughts?
