I want to be able to manage an egg cache to be used in a local
installation workflow: download the package and build the eggs in a
defined directory.
E.g. Like what Buildout does for you?
Haven't looked at this. Will do, thank you.
I first download the package using the documented
Hi,
In our environment, we are using the scripts parameter to package external
binary files, which is really a practical use case:
1) it allows for bundling of executables in our package python distribution
(with pertaining dlls etc)
2) the binary is available in an activated virtualenv
For
On 17 July 2014 17:04, David Genest david.gen...@ubisoft.com wrote:
I would like to know what is the take in the community on this.
My view would be:
1. The scripts argument is for *scripts* not binary files, so it is perfectly
correct to open them in text mode, do line ending
For the record, the current draft of the python.commands extension in PEP 459
does indeed include support for reporting prebuilt
commands:
http://www.python.org/dev/peps/pep-0459/#the-python-commands-extension
The draft metadata extensions haven't really been properly reviewed yet,
Hey there,
I'm using python 2.7/setuptools 3.6 to build an egg of my code (checked into
perforce) using my setup.py. This egg gets installed into a virtualenv.
On osx/darwin this works fine.
On windows, the bdist creates scripts and data whose permissions are
read-only (attrib+r), and
1. Post-install steps included in setup.py. That should be covered by the
support in Metadata 2.0. I'd also be interested in how much of an issue
omitting the postinstall would be in practice (for instance many such steps
just set up Start Menu type shortcuts, which are not essential for the
Hi,
I was wondering what is the recommended approach to bundling runtime dll
dependencies when using wheels.
We are migrating from egg to wheels for environment installation and of various
python dependencies.
Some of those have extension modules, and some have extension modules that
This is not true. Python loads DLLs with LOAD_WITH_ALTERED_SEARCH_PATH, to
allow them to be located alongside the pyd file. You should therefore be able
to ship the
dependent dll in the package directory (which wheels support fine).
Paul
Ok, so what if the dll is shared in a given
Thank you all for the precious info.
Here are my observations:
- We are merely writing extension modules with third party dependant code
packaged in a dll. In my mind, this use case is not the exception, and would
not necessarily warrant the use of a full blown solution like conda. Our
Note that PEP 459 currently proposes preserving this capability as
python.commands.prebuilt, so I personally consider it reasonable as a way
of packaging arbitrary
executables and non-entry-point based scripts.
Yes, this will prove valuable (for other things than dlls, admittedly).
The
Hi,
Is there by any chance an opening to include UNC path support in pip 6?
I made a Pull request (https://github.com/pypa/pip/pull/1834) some time ago,
which received positive attention from Steve Dower, but nobody else commented
on the patch.
This is linked to
11 matches
Mail list logo
