On Mon, Dec 15, 2014 at 6:48 PM, Donald Stufft don...@stufft.io wrote:
On Dec 15, 2014, at 6:46 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Maurits van Rees schreef op 15-12-14 23:50:
TMP2/setuptools-8.0.4-py2.7.egg/pkg_resources.py:2425: RuntimeWarning:
'zc.buildout-2.3.0 ()'
On Mon, Dec 15, 2014 at 01:45:28PM -0500, Donald Stufft wrote:
On Dec 15, 2014, at 1:27 PM, Jim Fulton j...@zope.com wrote:
I think the changes in version management in setuptools 8 are a
great step forward, but I think the transition is going to hurt a
lot.
For buildout, I'm
This:
- Fixes the picked-version bug
- Suppresses spurious (and not spurious) legacy version warnings.
(When that setuptools/packaging problem is fixed. I'll release 2.3.2
that undoes this.)
If we're still in significant pain tomorrow, then I'll release a 2.4
that requires setuptools 8.
On Tue, Dec 16, 2014 at 2:48 AM, Donald Stufft don...@stufft.io wrote:
On Dec 15, 2014, at 6:46 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Maurits van Rees schreef op 15-12-14 23:50:
TMP2/setuptools-8.0.4-py2.7.egg/pkg_resources.py:2425: RuntimeWarning:
'zc.buildout-2.3.0 ()' is
On 2014-12-16 02:25:33 -0500 (-0500), Donald Stufft wrote:
Openstack won’t be providing one, they are adapting server to PEP
440 syntax.
[...]
Confirmed, we're very close now and will likely be interoperating
with Setuptools 8 in our test infrastructure for all supported
branches later this
Jim Fulton schreef op 16-12-14 14:13:
This:
- Fixes the picked-version bug
- Suppresses spurious (and not spurious) legacy version warnings.
(When that setuptools/packaging problem is fixed. I'll release 2.3.2
that undoes this.)
If we're still in significant pain tomorrow, then I'll
On Tue, Dec 16, 2014 at 5:08 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-12-16 02:25:33 -0500 (-0500), Donald Stufft wrote:
Openstack won’t be providing one, they are adapting server to PEP
440 syntax.
[...]
Confirmed, we're very close now and will likely be interoperating
with
On 2014-12-16 18:11:12 +0300 (+0300), anatoly techtonik wrote:
It would be more useful if the powers behind OpenStack could sponsor
development of proper PEP scheme to untangle its own workflow instead
of relying on imperfect PEP solutions that are being done by
volunteers in their free time.
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
On 16 December 2014 at 16:21, David Genest david.gen...@ubisoft.com wrote:
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
On Dec 16, 2014, at 10:40 AM, Jeremy Stanley fu...@yuggoth.org wrote:
The way I see it, we're all volunteers. We voluntarily work on free
software and associated support infrastructure. Some of us are
simply lucky enough to find sponsors willing to pay us to do it full
time (and while I
On Tue, Dec 16, 2014 at 11:48 AM, Donald Stufft don...@stufft.io wrote:
...
Yea, I’m incredibly lucky to have found someone willing to pay me for my
hobby. Rackspace pays me to work on Python packaging
Thanks Rackspace!
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
I’ve had a number of people complain that PEP 440 normalizes a release
candidate as 1.0c1 instead of 1.0rc1. Do we want to ammend the PEP to switch
the normalization around so that it normalizes 1.0c1 to 1.0rc1? This probably
matches what people expect better in general? It wouldn't have any
On Dec 16, 2014, at 12:56 PM, Donald Stufft don...@stufft.io wrote:
I’ve had a number of people complain that PEP 440 normalizes a release
candidate as 1.0c1 instead of 1.0rc1. Do we want to ammend the PEP to switch
the normalization around so that it normalizes 1.0c1 to 1.0rc1? This
On 16 December 2014 at 17:56, Donald Stufft don...@stufft.io wrote:
I’ve had a number of people complain that PEP 440 normalizes a release
candidate as 1.0c1 instead of 1.0rc1. Do we want to ammend the PEP to switch
the normalization around so that it normalizes 1.0c1 to 1.0rc1? This probably
After an offline discussion with Donald regarding feedback on the
setuptools 8.0 release, I'm proposing we change the status of PEP 440 to be
Provisional (in the PEP 411 sense) until we sort out the additional issues
that were revealed through actual adoption.
I can't actually make that change to
On Dec 16, 2014, at 6:01 PM, Nick Coghlan ncogh...@gmail.com wrote:
After an offline discussion with Donald regarding feedback on the setuptools
8.0 release, I'm proposing we change the status of PEP 440 to be Provisional
(in the PEP 411 sense) until we sort out the additional issues that
I wanted to try out local version identifiers for packages. Or
actually, I already used them, but with a wrong notation, and ran into
trouble, also after fixing the notation. So I did some testing and
made notes on what does or does not work. See conclusions at the
bottom.
Local version
On 16 December 2014 at 23:53, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
BUG in pip: development version of pip cannot find local version
identifiers (version numbers with a plus sign).
Have you logged that bug with pip? If not, could you? It sounds like
it's something that should
On Dec 16, 2014, at 6:53 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
words
Yea, it’s unfortunate that local versions don’t work prior to setuptools 8.0,
but the
older versions more or less escape everything that’s not alpha numeric and .
and - to
the - character so there’s
On 2014-12-17 00:53:08 +0100 (+0100), Maurits van Rees wrote:
[...]
File .../pip/_vendor/pkg_resources.py, line 2583, in scan_list
Expected ',' or end-of-list in,line,at,line[p:]
ValueError: (Expected ',' or end-of-list in,
'myproject==1.1+maurits.3', 'at', '+maurits.3')
Maurits van Rees schreef op 17-12-14 00:53:
I have created a very basic python project called 'myproject'. It
does nothing. I have released a few versions here:
http://pypi.zestsoftware.nl/public/packagingtest/
I have now also distributed myproject version 1.1. (This has a
base.jinja2 file
On Dec 16, 2014, at 7:46 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Maurits van Rees schreef op 17-12-14 00:53:
I have created a very basic python project called 'myproject'. It
does nothing. I have released a few versions here:
Donald Stufft schreef op 17-12-14 01:54:
On Dec 16, 2014, at 7:46 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Maurits van Rees schreef op 17-12-14 00:53:
I have created a very basic python project called 'myproject'. It
does nothing. I have released a few versions here:
On Dec 16, 2014, at 8:33 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Donald Stufft schreef op 17-12-14 01:54:
On Dec 16, 2014, at 7:46 PM, Maurits van Rees m.van.r...@zestsoftware.nl
wrote:
Maurits van Rees schreef op 17-12-14 00:53:
I have created a very basic python
On 12/16/2014 05:49 PM, Donald Stufft wrote:
So the *primary* use case that motivated local versions is things like when
Debian
patches a copy of a project they can indicate that they’ve done so by
changing the
version to 1.0+dfsg1 or so instead of 1.0. A related use case is the one
On Dec 16, 2014, at 9:10 PM, Ethan Furman et...@stoneleaf.us wrote:
On 12/16/2014 05:49 PM, Donald Stufft wrote:
So the *primary* use case that motivated local versions is things like when
Debian
patches a copy of a project they can indicate that they’ve done so by
changing the
On 12/16/2014 06:48 PM, Donald Stufft wrote:
Now if you have 1.3+debian1 installed via apt-get (or any means really), and
you’ll get the following behaviors (show with pip):
- pip install yourthing - 1.3+debian1 satisfies the constraint of anything,
so it stays installed.
- pip install
Oh, to be clear: There are no guarantees that 1.4 actually includes the
bug-fixes in +debian1, correct? It's just a
big hope?
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Dec 16, 2014, at 10:25 PM, Ethan Furman et...@stoneleaf.us wrote:
On 12/16/2014 06:48 PM, Donald Stufft wrote:
Now if you have 1.3+debian1 installed via apt-get (or any means really), and
you’ll get the following behaviors (show with pip):
- pip install yourthing - 1.3+debian1
30 matches
Mail list logo
