Thanks for the confirmation that my interpretation was wrong. This
makes things a lot better :-)
More below...
On 29.09.2014 11:39, Nick Coghlan wrote:
On 29 Sep 2014 18:49, M.-A. Lemburg m...@egenix.com wrote:
You are missing out on cases, where the release process causes files to
be
On 30 Sep 2014 19:06, M.-A. Lemburg m...@egenix.com wrote:
You're regularly bringing up this argument.
Let's just be fair here: external hosting of packages has been made so
user unfriendly in recent pip releases, that this has pretty much
become a non-option for anyone who wants to create a
On 30 September 2014 10:06, M.-A. Lemburg m...@egenix.com wrote:
Let's just be fair here: external hosting of packages has been made so
user unfriendly in recent pip releases, that this has pretty much
become a non-option for anyone who wants to create a user friendly
package installation
On September 30, 2014 at 5:07:06 AM, M.-A. Lemburg (m...@egenix.com) wrote:
Thanks for the confirmation that my interpretation was wrong. This
makes things a lot better :-)
More below...
On 29.09.2014 11:39, Nick Coghlan wrote:
On 29 Sep 2014 18:49, M.-A. Lemburg wrote:
You are
On 30 September 2014 21:30, Donald Stufft don...@stufft.io wrote:
In pip 1.5.x (current latest release) people can add additional indexes (or
replace PyPI all together) on a per user basis. In pip 6.0 (next release) that
still exists, and in addition it also includes a global configuration file
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
On 30 September 2014 14:32, David Genest david.gen...@ubisoft.com wrote:
But the only way to get a dependent dll found on windows is to have it on
PATH, and the scripts directory on
windows is on path when a virtualenv is activated.
This is not true. Python loads DLLs with
On 28 August 2014 19:58, Donald Stufft don...@stufft.io wrote:
To fix this I'm going to modify PyPI so that it uses the normalized name in
the /simple/ URL and redirects everything else to the non-normalized name.
I'm also going to submit a PR to bandersnatch so that it will use normalized
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
On 2014-09-30 07:26:32 -0400 (-0400), Donald Stufft wrote:
[...]
I don’t personally believe it makes sense for a source
distribution to have a build number.
[...]
I'm becoming less and less convinced it actually *is* a source
distribution any more. My constant interaction with downstream Linux
On 30 September 2014 15:31, David Genest david.gen...@ubisoft.com wrote:
Ok, so what if the dll is shared in a given environment (multiple extensions
use it)?, the shared dll should be copied to every package? Won't that cause
multiple loads by the system?
I honestly don't know in that
On 2014-09-30 11:06:40 +0200 (+0200), M.-A. Lemburg wrote:
[...]
You're regularly bringing up this argument.
Let's just be fair here: external hosting of packages has been
made so user unfriendly in recent pip releases, that this has
pretty much become a non-option for anyone who wants to
On 1 October 2014 00:37, Paul Moore p.f.mo...@gmail.com wrote:
On 30 September 2014 15:31, David Genest david.gen...@ubisoft.com wrote:
Ok, so what if the dll is shared in a given environment (multiple extensions
use it)?, the shared dll should be copied to every package? Won't that
cause
Or you could just create a Python package that only contains the dll,
and depend on it from your others.
On Tue, Sep 30, 2014 at 10:44 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 1 October 2014 00:37, Paul Moore p.f.mo...@gmail.com wrote:
On 30 September 2014 15:31, David Genest
On 30 September 2014 15:45, Daniel Holth dho...@gmail.com wrote:
Or you could just create a Python package that only contains the dll,
and depend on it from your others.
The problem is getting the DLL on PATH.
What you could do is distribute a package containing:
1. The dll
2. An __init__.py
On 30 September 2014 11:35, Robin Becker ro...@reportlab.com wrote:
What would be the objection to removing or nulling a release package that
had actual malware embedded in it some how. It seems reasonable to have some
last resort take down mechanism.
None at all. Removal is specifically still
On 29/09/2014 10:50, Nick Coghlan wrote:
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users who have already installed
On 30 September 2014 15:25, Paul Moore p.f.mo...@gmail.com wrote:
On 28 August 2014 19:58, Donald Stufft don...@stufft.io wrote:
To fix this I'm going to modify PyPI so that it uses the normalized name in
the /simple/ URL and redirects everything else to the non-normalized name.
I'm also
On 09/30/2014 08:41 AM, Nick Coghlan wrote:
Why is your setup.py sdist including autogenerated content? It
shouldn't be doing that.
Don't almost all sdists? At the very least egg-info is autogenerated,
MANIFEST usually is too.
Carl
___
Distutils-SIG
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as a distribution
file carrying 3.1.4 in its file name.
Please don't literally use 3.1.4-1. That will cause all kinds of havoc with
the
On 30 Sep 2014, at 17:35, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as a distribution
file carrying 3.1.4 in its file name.
Please
On 2014-09-30 09:22:29 -0600 (-0600), Carl Meyer wrote:
On 09/30/2014 08:41 AM, Nick Coghlan wrote:
Why is your setup.py sdist including autogenerated content? It
shouldn't be doing that.
Don't almost all sdists? At the very least egg-info is
autogenerated, MANIFEST usually is too.
Thank you very Steve for pushing that installer out, this is very appreciated.
What is the story for project maintainers who want to also support
Python 3.3+ (for 32 bit and 64 bit python) for their project with
binary wheels for windows? At the moment it's possible to use the
Windows SDK as
On 30 September 2014 16:56, Olivier Grisel olivier.gri...@ensta.org wrote:
What is the story for project maintainers who want to also support
Python 3.3+ (for 32 bit and 64 bit python) for their project with
binary wheels for windows?
It would be so easy at this point to ask What's the chance
Olivier Grisel wrote:
Thank you very Steve for pushing that installer out, this is very appreciated.
What is the story for project maintainers who want to also support Python 3.3+
(for 32 bit and 64 bit python) for their project with binary wheels for
windows?
At the moment it's possible
On Sep 30, 2014, at 02:34 PM, Jeremy Stanley wrote:
I'm becoming less and less convinced it actually *is* a source
distribution any more. My constant interaction with downstream Linux
distro packagers shows a growing disinterest in consuming release
tarballs of software, that they would generally
On Sep 30, 2014, at 05:40 PM, Wichert Akkerman wrote:
Debian does allow 3.1.4-1-1. I forgot the exact rules, but I seem to remember
the package version is considered to start after the last dash. Debian will
also sort 3.1.4a after 3.1.4 unlike Python rules, so version “massaging”
might be
On 2014-09-30 12:07:23 -0400 (-0400), Barry Warsaw wrote:
We had a discussion about this at the recently concluded Debian
conference. There are folks who only want to use git tags as the
consumption point for Debian packages, but this opinion was not
the majority opinion.
Good to know. The
On 30 September 2014 17:07, Steve Dower steve.do...@microsoft.com wrote:
The answer is basically no chance - the slippery slope was considered and
shut down.
Fair enough. Actually, it's good to know that this sort of thing was
thought through.
If VC14 slips significantly and we have to stick
On Sep 30, 2014, at 04:25 PM, Jeremy Stanley wrote:
Good to know. The Debian Developer packaging the majority of the
projects I work on must be in that minority.
IIRC, the OpenStack packagers were probably the most prominent proponent of
release-from-tag.
Cheers,
-Barry
signature.asc
On 1 October 2014 04:40, Wichert Akkerman wich...@wiggy.net wrote:
On 30 Sep 2014, at 17:35, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
Installers and PyPI would then regard 3.1.4-1 as belonging to
release 3.1.4, but being a more current build as
On Sep 30, 2014, at 11:14 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 30 September 2014 15:25, Paul Moore p.f.mo...@gmail.com wrote:
On 28 August 2014 19:58, Donald Stufft don...@stufft.io wrote:
To fix this I'm going to modify PyPI so that it uses the normalized name in
the /simple/ URL
David Genest wrote:
Subject: Re: [Distutils] Wheels and dependent third party dlls on windows
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
On Tue, Sep 30, 2014 at 3:31 PM, David Genest david.gen...@ubisoft.com
wrote:
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
On Tue, Sep 30, 2014 at 3:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 1 October 2014 00:37, Paul Moore p.f.mo...@gmail.com wrote:
On 30 September 2014 15:31, David Genest david.gen...@ubisoft.com
wrote:
Ok, so what if the dll is shared in a given environment (multiple
extensions use
Hi,
I was curious what others do for the following packaging tasks, or if
you have any recommendations otherwise. There is also a code
organization question at the end.
1) For starters, it's very easy to make mistakes in one's MANIFEST.in,
so I hacked the sdist command in my setup.py to list
On Sep 30, 2014, at 7:44 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote:
Hi,
I was curious what others do for the following packaging tasks, or if
you have any recommendations otherwise. There is also a code
organization question at the end.
1) For starters, it's very easy to make
37 matches
Mail list logo
