[Distutils] distlib.mount API design (was: wheels on sys.path clarification (reboot))

2014-01-30 Thread Nick Coghlan
to implement in a robust manner. mount() would become something I could explore when I had some additional free time (hah!), rather than something I felt obliged to help get to a more robust state before releasing metadata 2.0. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane

Re: [Distutils] PEP 427

2014-01-30 Thread Nick Coghlan
On 31 Jan 2014 02:48, Donald Stufft don...@stufft.io wrote: How am i supposed to manage that using pip and virtual envs in production? The same way you'd use them in development? Hell I believe you can even do: $ virtualenv my_virtualenv $ my_virtualenv/bin/pip install

Re: [Distutils] Using Wheel with zipimport

2014-01-30 Thread Nick Coghlan
Thanks for pointing that out Noah - I was planning to come back and check if that wording was considered more acceptable. On 31 Jan 2014 07:12, Donald Stufft don...@stufft.io wrote: The updated text is fine with me as it at least accurately documents the fact that using that feature is fraught

Re: [Distutils] distlib.mount API design (was: wheels on sys.path clarification (reboot))

2014-01-30 Thread Nick Coghlan
On 30 Jan 2014 23:26, Paul Moore p.f.mo...@gmail.com wrote: On 30 January 2014 12:29, Nick Coghlan ncogh...@gmail.com wrote: I actually think this is a useful thing to experiment with, I'm just not sure distlib is the best place for that experiment. With appropriately secure tempfile

Re: [Distutils] platform specific python only wheels

2014-01-31 Thread Nick Coghlan
On 31 Jan 2014 04:41, Daniel Holth dho...@gmail.com wrote: You are probably a perfect customer for supports_environment It occurs to me that if we split the hooks stuff out of PEP 359, we'd be pretty close to a releasable metadata 2.0 spec... Cheers, Nick. On Thu, Jan 30, 2014 at 1:40 PM,

Re: [Distutils] Extracting C extensions from zipfiles on sys.path (Was: wheels on sys.path clarification (reboot))

2014-01-31 Thread Nick Coghlan
On 31 Jan 2014 21:00, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Fri, 31/1/14, Thomas Heller thel...@ctypes.org wrote: This limitation does no longer exist; it works in 2.x and 3.x as well as on 32-bit and 64-bit. That's good to know. Of course, as it's platform specific, it can't be

Re: [Distutils] Letting the Python implementation produce the Python ABI tag

2014-01-31 Thread Nick Coghlan
for CPython, PyPy, IronPython and Jython to help avoid filenames getting excessively long in the typical case, but the underlying concept is still based on the SOABI tag introduced in PEP 3149. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-01-31 Thread Nick Coghlan
tools approved, but also has the inherent downside of Python version dependent differences in available features and behaviour. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-02-01 Thread Nick Coghlan
Python versions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-02-01 Thread Nick Coghlan
On 1 February 2014 18:50, Noah Kantrowitz n...@coderanger.net wrote: On Feb 1, 2014, at 12:43 AM, Nick Coghlan ncogh...@gmail.com wrote: That said, something I mentioned to the OpenStack folks a while ago (and I think on this list, but potentially not), is that I have now realised the much

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-02-01 Thread Nick Coghlan
On 1 February 2014 19:29, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Sat, 1/2/14, Nick Coghlan ncogh...@gmail.com wrote: FWIW, installing into a venv from outside it works fine That's what I'm saying :-) However, it's substantially *harder* to explain to people how to use it correctly

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-02-01 Thread Nick Coghlan
, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python)

2014-02-01 Thread Nick Coghlan
On 1 February 2014 22:20, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Sat, 1/2/14, Nick Coghlan ncogh...@gmail.com wrote: My point is that doing it the way virtualenv/pip did avoided a bunch of design work and associated testing, and reduced the opportunities for bugs - when you're trying

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
to be updated when a new version of pip is released, it *also* makes testing with different versions straightforward. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https

Re: [Distutils] restart-in-venv

2014-02-04 Thread Nick Coghlan
Fedora 19 still ships pip 1.3.1. Fedora 20 ships pip 1.4.1. Fedora 21 will probably ship 1.5.2 (although that hasn't actually happened yet, so Rawhide still has 1.4.1). The relative alignment of the release cycles is such that the pip version system Python will always be about 6 months behind

Re: [Distutils] PEP-459 feedback from openSUSE packaging

2014-02-04 Thread Nick Coghlan
classifiers (https://pypi.python.org/pypi?%3Aaction=list_classifiers) and projects could start listing them in their current metadata. Something like: License :: SPDX :: tag Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] PEP-459 feedback from openSUSE packaging

2014-02-04 Thread Nick Coghlan
On 5 February 2014 00:05, Daniel Holth dho...@gmail.com wrote: On Tue, Feb 4, 2014 at 9:02 AM, Nick Coghlan ncogh...@gmail.com wrote: Oh, I hadn't seen SPDX before - very interesting. I'm wondering if it may be a better fit for the PyPI Trove classifiers though - then it wouldn't even need

Re: [Distutils] restart-in-venv

2014-02-04 Thread Nick Coghlan
On 5 February 2014 00:00, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Tue, 4/2/14, Nick Coghlan ncogh...@gmail.com wrote: It's a higher level of isolation than that offered by *not* installing pip into the virtual environments - the two approaches are *not* equivalent, and one

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
users? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] restart-in-venv

2014-02-04 Thread Nick Coghlan
with the consequences of cert file unpacking, etc. Somehow, I don't see that getting anywhere near the top of anyone's priority list any time soon. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
On 5 February 2014 01:48, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Tue, 4/2/14, Nick Coghlan ncogh...@gmail.com wrote: That only works if the system site packages is configured to be visible inside the virtual environment - it usually isn't these days. If that were true, distil

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
On 5 February 2014 01:59, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: On Tue, 4/2/14, Nick Coghlan ncogh...@gmail.com wrote: Vinay, please let it drop. You accuse us of FUD, yet have presented no evidence that your approach works flawlessly across multiple versions of Fedora, Debian

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

2014-02-04 Thread Nick Coghlan
On 5 February 2014 02:25, Barry Warsaw ba...@python.org wrote: On Feb 05, 2014, at 01:05 AM, Nick Coghlan wrote: That only works if the system site packages is configured to be visible inside the virtual environment - it usually isn't these days. Really? I do this all the time. It prevents

Re: [Distutils] wheel building help needed

2014-02-06 Thread Nick Coghlan
Evgeny, while you can probably make wheels do what you want, if you're interested in single file executables, you're almost certainly better off using one of the tools designed to make those easier to work with (like Twitter's recently discussed PEX format, or PEP 441). As you have discovered,

Re: [Distutils] guidance for contributing to packaging docs

2014-02-09 Thread Nick Coghlan
in the user guide tracker; I'm currently working on pip and setuptools) As for the python.org docs, Nick Coghlan has already added notes to the top of the old Installing/Distributing Python Modules guides pointing to the new packaging user guide. Eventually, both of the old guides need

[Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-23 Thread Nick Coghlan
of the acceptance of PEP 426. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Deleting legacy contents from core install guide?

2014-02-23 Thread Nick Coghlan
guide in 3.4+, it can become just a very, very simple introduction to the core pip commands, and then a reference out to the packaging user guide for more info. Thoughts? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] Deleting legacy contents from core install guide?

2014-02-23 Thread Nick Coghlan
On 23 February 2014 22:00, Paul Moore p.f.mo...@gmail.com wrote: On 23 February 2014 11:43, Nick Coghlan ncogh...@gmail.com wrote: With that content gone from the end user installation guide in 3.4+, it can become just a very, very simple introduction to the core pip commands

Re: [Distutils] Deleting legacy contents from core install guide?

2014-02-23 Thread Nick Coghlan
On 24 Feb 2014 07:48, Marcus Smith qwc...@gmail.com wrote: However, after thinking a little more on the challenge, I believe the lower level legacy content should fit right in as a new subsection in the distutils docs at http://docs.python.org/3/distutils/index.html. There's 3 things right

Re: [Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-26 Thread Nick Coghlan
On 27 Feb 2014 04:00, Donald Stufft don...@stufft.io wrote: I will accordingly be updating the defined metadata version in PEP 426 to 3.0, and including an explicit admonition to *never* include experimental metadata (whether in the base format or as part of an experimental extension) in

Re: [Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-26 Thread Nick Coghlan
On 27 Feb 2014 08:41, Paul Moore p.f.mo...@gmail.com wrote: On 26 February 2014 22:07, Donald Stufft don...@stufft.io wrote: We should probably start versioning dist-info directories. Probably. I'm not actually sure there's a formal spec for what's in a dist-info directory TBH. There's

Re: [Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-26 Thread Nick Coghlan
On 27 Feb 2014 08:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: If Vinay is happy with that last option for handling the current bdist_wheel misbehaviour that would mean we could leave the metadata version alone I've changed distlib to ignore pydist.json for wheels with version 1.0, where

Re: [Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-26 Thread Nick Coghlan
On 27 Feb 2014 10:16, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: PEP 425 explicitly covers that. It says The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead. PyPy should probably use its own versions here pp18, pp19. The

Re: [Distutils] The PEP 426 defined metadata version will be metadata 3.0

2014-02-27 Thread Nick Coghlan
list at this point. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Remaining tasks before metadata 2.0 can be accepted (was Re: The PEP 426 defined metadata version will be metadata 3.0)

2014-03-01 Thread Nick Coghlan
in the core PEPs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Remaining tasks before metadata 2.0 can be accepted (was Re: The PEP 426 defined metadata version will be metadata 3.0)

2014-03-01 Thread Nick Coghlan
On 2 March 2014 15:22, Nick Coghlan ncogh...@gmail.com wrote: On 27 February 2014 10:46, Marcus Smith qwc...@gmail.com wrote: that would be good. If you did, I would link to the tasks from the PUG future page. OK, these are the things I consider blockers for an accepted metadata 2.0 spec

[Distutils] Deferring metadata hooks

2014-03-01 Thread Nick Coghlan
), while still *allowing* developers to refuse to let the software install if the metadata hooks won't be run. Regards, Nick. P.S. The draft PEP for metadata hooks is still available at https://bitbucket.org/pypa/pypi-metadata-formats/src/default/metadata-hooks.rst -- Nick Coghlan | ncogh

Re: [Distutils] Deferring metadata hooks

2014-03-02 Thread Nick Coghlan
On 3 Mar 2014 04:34, Oscar Benjamin oscar.j.benja...@gmail.com wrote: On 2 March 2014 07:25, Nick Coghlan ncogh...@gmail.com wrote: I've just posted updated versions of PEP 426 and 459 that defer the metadata hooks feature. The design and behaviour of that extension is still way too

Re: [Distutils] Remaining tasks before metadata 2.0 can be accepted (was Re: The PEP 426 defined metadata version will be metadata 3.0)

2014-03-02 Thread Nick Coghlan
specifiers, whereas its predecessor just covered covered the version numbers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman

Re: [Distutils] OS X and PEP 425 / wheels

2014-03-07 Thread Nick Coghlan
___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] OS X and PEP 425 / wheels

2014-03-07 Thread Nick Coghlan
features (2.6, 2.7, 3.2, 3.3). You see similar behaviour from the platform vendors themselves. Microsoft Visual Studio and Red Hat's Developer Toolset, for example, are both versioned independently from the underlying OS. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane

Re: [Distutils] tourist here, with a dumb RTFM question

2014-03-08 Thread Nick Coghlan
On 9 Mar 2014 01:20, Nick Coghlan ncogh...@gmail.com wrote: On 9 Mar 2014 00:26, Jason R. Coombs jar...@jaraco.com wrote: I had incorrectly assessed the potential impact of this change. I had expected the impact to be minor and isolated. I underestimated the number of systems

Re: [Distutils] tourist here, with a dumb RTFM question

2014-03-08 Thread Nick Coghlan
On 9 Mar 2014 01:50, Daniel Holth dho...@gmail.com wrote: Some packaging systems do not have the same 1:1 source : distribution relationship that is so prominent in the distutils model. This should probably change long term. Huh, I hadn't thought about that, and I really should have, since

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-19 Thread Nick Coghlan
On 20 March 2014 09:54, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Daniel Holth dholth at gmail.com writes: extensions without using distutils. The problem of invoking the compiler has been solved by many build systems and is not just a unique and mysterious distutils feature. Did someone

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-21 Thread Nick Coghlan
without doing that, I don't believe we're going to understand the existing scope we need to cover for 2. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-22 Thread Nick Coghlan
be expected from a reimplementation, and what can be deemed setuptools specific. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-22 Thread Nick Coghlan
On 23 Mar 2014 09:35, Paul Moore p.f.mo...@gmail.com wrote: On 22 March 2014 22:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: 1. Formally decouple the setup.py CLI from the distutils command system Agreed - it looks like a compatible CLI needs to be part of the transition to any new

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-23 Thread Nick Coghlan
On 24 Mar 2014 00:13, Paul Moore p.f.mo...@gmail.com wrote: On 23 March 2014 00:00, Nick Coghlan ncogh...@gmail.com wrote: On 23 Mar 2014 09:35, Paul Moore p.f.mo...@gmail.com wrote: On 22 March 2014 22:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: 1. Formally decouple the setup.py CLI

Re: [Distutils] waf can be used to compile Python extension modules

2014-03-24 Thread Nick Coghlan
On 24 Mar 2014 10:01, Paul Moore p.f.mo...@gmail.com wrote: On 23 March 2014 23:13, Nick Coghlan ncogh...@gmail.com wrote: Now you begin to see the scope of the problem. It's definitely solvable, but means asking a whole pile of required, recommended or distutils-specific? questions about

Re: [Distutils] setuptools tracker

2014-03-24 Thread Nick Coghlan
with appropriately. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] What is the syntax for passing conditional non-extra dependencies in setuptools?

2014-03-27 Thread Nick Coghlan
On 28 Mar 2014 04:40, PJ Eby p...@telecommunity.com wrote: On Wed, Mar 26, 2014 at 11:29 PM, Daniel Holth dho...@gmail.com wrote: How do I specify a conditional (marker-guarded) non-extra dependency in setuptools? The syntax for a conditional extra dependency is currently:

Re: [Distutils] Is build an inherently arbitrary-code process?

2014-03-27 Thread Nick Coghlan
On 28 Mar 2014 05:42, Daniel Holth dho...@gmail.com wrote: I became convinced that build was an inherently arbitrary-code process, and not something to be universally handled by a declarative system, It wasn't an accident that last years PyCon panel was subtitled setup.py *install* must die

Re: [Distutils] What is the syntax for passing conditional non-extra dependencies in setuptools?

2014-03-27 Thread Nick Coghlan
On 28 Mar 2014 07:16, Nick Coghlan ncogh...@gmail.com wrote: On 28 Mar 2014 04:40, PJ Eby p...@telecommunity.com wrote: On Wed, Mar 26, 2014 at 11:29 PM, Daniel Holth dho...@gmail.com wrote: How do I specify a conditional (marker-guarded) non-extra dependency in setuptools? The syntax

Re: [Distutils] Versioned entry points

2014-03-28 Thread Nick Coghlan
On 29 Mar 2014 06:20, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Does anyone have any thoughts? Note that there is one situation where scripts for multiple Python versions reside in the same directory: per-user site-packages (PEP 370). If you install a package which has scripts and you don't

Re: [Distutils] Versioned entry points

2014-03-28 Thread Nick Coghlan
On 29 March 2014 07:23, Paul Moore p.f.mo...@gmail.com wrote: On 28 March 2014 21:06, Nick Coghlan ncogh...@gmail.com wrote: So consider me in the school that suggests this be a standard installer feature that can be applied to any entry point script, rather than something that varies

Re: [Distutils] Pycon

2014-03-28 Thread Nick Coghlan
talk first as a year in review kind of thing to remind us of how far we've come since this time last year) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https

Re: [Distutils] Pycon

2014-03-29 Thread Nick Coghlan
wandering between a lot of different sprint rooms at the rate this is going...) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo

Re: [Distutils] DOAP on PyPI

2014-03-29 Thread Nick Coghlan
is dead is correct. So yeah, skipping implementing those URLs for the migration makes sense to me. If anyone complains, we can always add them back later (I doubt anyone will complain, though). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] Pycon

2014-03-31 Thread Nick Coghlan
On 1 Apr 2014 03:26, Barry Warsaw ba...@python.org wrote: On Mar 28, 2014, at 03:06 PM, Daniel Holth wrote: Who is going to pycon? I will be there. I'll be there, for the duration (language summit through sprints). It would be great to hav an OpenSpace or BoF for discussing the

Re: [Distutils] Creating distribution for Python *module*, not package

2014-04-01 Thread Nick Coghlan
On 2 Apr 2014 06:41, Paul Moore p.f.mo...@gmail.com wrote: On 1 April 2014 21:16, Michael Merickel mmeri...@gmail.com wrote: Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to only document its new features. This approach to documentation makes it very difficult to

Re: [Distutils] install_requires vs. requires_dist, and setup.cfg

2014-04-07 Thread Nick Coghlan
On 7 Apr 2014 00:59, Marcus Smith qwc...@gmail.com wrote: From what I understand in PEP 345, Requires-Dist is the name in PKG-INFO files for a distribution's dependencies on other distributions. setuptools/distutils has never implemented Requires-Dist from PEP345 for PKG-INFO. Otoh, wheel

Re: [Distutils] What is the syntax for passing conditional non-extra dependencies in setuptools?

2014-04-07 Thread Nick Coghlan
On 7 Apr 2014 15:09, Daniel Holth dho...@gmail.com wrote: I think setuptools' :-separated environment markers mechanism is great, and shouldn't need to be ratified anywhere. I also think the actual environment markers specification is stable, although I noticed the IPython wheel for example

Re: [Distutils] Comments on PEP 426 and 459

2014-04-07 Thread Nick Coghlan
On 7 Apr 2014 23:15, Daniel Holth dho...@gmail.com wrote: I read through the latest versions of PEP 426 and 459 Metadata 2.0 and extensions. Here are my comments. The PEP suggests setup.py dist_info is a thing. Only setup.py egg_info works. It might make sense to refactor bdist_wheel to

Re: [Distutils] Distribution and packaging mini-summit at PyCon: today 5 to 6

2014-04-13 Thread Nick Coghlan
On 12 Apr 2014 20:36, Daniel Holth dho...@gmail.com wrote: On Fri, Apr 11, 2014 at 6:19 PM, Éric Araujo mer...@netwok.org wrote: Hi, One hour was awfully short. Noah did a short review of the past year and a half, Richard talked about future plans for PyPI, Nick clarified some

Re: [Distutils] Distribution and packaging mini-summit at PyCon: today 5 to 6

2014-04-15 Thread Nick Coghlan
. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Enterprise Python - Multicomponent Projects

2014-04-16 Thread Nick Coghlan
with downstream redistributors (whether Linux distros, redistributors like Enthought, ActiveState and Continuum Analytics or custom in-house deployment mechanisms). -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG

Re: [Distutils] PEP440 Local versions idea in rpm/deb?

2014-05-02 Thread Nick Coghlan
On 2 May 2014 13:15, Marcus Smith qwc...@gmail.com wrote: not clear at all how you're answering the question. Local version in the PEP corresponds to the distro release concept. We can't use that specific terminology because we already use release to mean something else. Cheers, Nick. The

Re: [Distutils] PEP440 Local versions idea in rpm/deb?

2014-05-02 Thread Nick Coghlan
On 2 May 2014 13:33, Marcus Smith qwc...@gmail.com wrote: On Fri, May 2, 2014 at 1:15 PM, Donald Stufft don...@stufft.io wrote: I’m pretty sure all the distros have some equivalent to it, often times with similar syntax. e.g. look here

[Distutils] ensurepip in Python 2.7

2014-05-02 Thread Nick Coghlan
Hey all, The next 2.7 release is coming up in a few weeks, and work is still needed on getting the SSL infrastructure updated. That release will likely also be the first one with Steve Dower at the helm for the creation of the Windows installers. Accordingly, I think it makes sense to leave

Re: [Distutils] PEP440 Local versions idea in rpm/deb?

2014-05-03 Thread Nick Coghlan
On 3 May 2014 16:44, Marcus Smith qwc...@gmail.com wrote: name-version-release I see the confusion now. I'm asking if there is a formal convention for localizing the release value? That's up to the distro, and is likely to be based on conventions and package manager features rather than

Re: [Distutils] ensurepip in Python 2.7

2014-05-03 Thread Nick Coghlan
On 4 May 2014 00:48, Steve Dower steve.do...@microsoft.com wrote: If I can get everything to build, that is... :-\ (it's not too bad - just the 64-bit installer giving me trouble, and Martin's helping out. 2.7.7's installer may be late...) On the bright side, Microsoft has apparently decided

Re: [Distutils] PEP440 Local versions idea in rpm/deb?

2014-05-05 Thread Nick Coghlan
On 6 May 2014 08:48, Marcus Smith qwc...@gmail.com wrote: In the custom RPM case, the PEP 440 local version and the leading numeric portion of the RPM release should *still* be the same (just as they should be for distro packages), but you'd choose a different local version/RPM release value

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-10 Thread Nick Coghlan
On 10 May 2014 08:03, Paul Moore p.f.mo...@gmail.com wrote: On 9 May 2014 22:33, Donald Stufft don...@stufft.io wrote: On the flip side option (A) allows us to make this much simpler overall. We can simply do: If it's hosted on PyPI: Trust it. else if it's not hosted

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
On 10 May 2014 22:24, Paul Moore p.f.mo...@gmail.com wrote: On 10 May 2014 12:57, Nick Coghlan ncogh...@gmail.com wrote: Actually, I expect folks like Stefan MvL would likely want to be able to preserve the current --allow-external behaviour. The change Donald is suggesting could

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
On 11 May 2014 17:58, Paul Moore p.f.mo...@gmail.com wrote: On 11 May 2014 08:38, Nick Coghlan ncogh...@gmail.com wrote: This confusion can likely be resolved by giving the obvious allow external name to the behaviour most users will want, and a more obscure name like allow verifiable

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
On 11 May 2014 23:18, Donald Stufft don...@stufft.io wrote: You’re worried that this change is a (or will at least be perceived as such) FU to Stefan and MAL, I’m worried that not fixing this is a FU to *everyone else*. Keep in mind that I am *agreeing* that allow external at the package level

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
On 12 May 2014 08:12, Donald Stufft don...@stufft.io wrote: On May 11, 2014, at 6:04 PM, Nick Coghlan ncogh...@gmail.com wrote: So, re-reading that, my preference is for option 3: keeping the global allow-all-external flag, but renaming it as something like allow-all-verifiable-external. It's

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
On 12 May 2014 09:35, Donald Stufft don...@stufft.io wrote: On May 11, 2014, at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote: Specifically, what I would recommend is: 1. Remove any references to the global flag from other documentation and error messages - always recommend the use of per

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-11 Thread Nick Coghlan
), the --allow-all-external option would be deprecated in 1.6 and removed in 1.7, and --allow-all-verifiable-external would be added as a non-deprecated spelling for the not-necessarily-subject-to-US-export-laws external hosting support. At-least-we're-not-dealing-with-ITAR-ly yours, Nick. -- Nick Coghlan

Re: [Distutils] PEP 438, pip and --allow-external (was: pip: cdecimal an externally hosted file and may be unreliable from python-dev)

2014-05-12 Thread Nick Coghlan
On 12 May 2014 15:39, Donald Stufft don...@stufft.io wrote: On May 12, 2014, at 12:50 AM, Nick Coghlan ncogh...@gmail.com wrote: There are some more notable names in the unsafe lists, but a few spot checks on projects like PyGObject, PyGTK, biopython, dbus-python, django-piston, ipaddr

Re: [Distutils] Need for respect (was: PEP 438, pip and --allow-external)

2014-05-12 Thread Nick Coghlan
in general, but are instead a supplemental license ensuring that PyPI mirroring, along with automated installation and use of packages is always permitted for all uploaded packages. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Distutils] Metabuild hooks

2014-05-12 Thread Nick Coghlan
On 13 May 2014 08:03, Paul Moore p.f.mo...@gmail.com wrote: The current approach is to solve 90% of the problem by noting that nearly all projects don't take advantage of any of the (usually undocumented) flexibility that distutils allows. This has thus far been a great success, in terms of

Re: [Distutils] PEP 470 - Using Multi Index Support for External to PyPI Package File Hosting

2014-05-14 Thread Nick Coghlan
On 15 May 2014 01:07, Donald Stufft don...@stufft.io wrote: I’ve just published a draft of PEP 470 - Using Multi Index Support for External to PyPI Package File Hosting You can see this online at http://legacy.python.org/dev/peps/pep-0470/ or read below For the record: I reviewed Donald's

Re: [Distutils] PEP 470 - Using Multi Index Support for External to PyPI Package File Hosting

2014-05-15 Thread Nick Coghlan
in the base OS EPEL can be upgraded. However, even with that, the server side links may still need to stick around for a while longer to account for the various distro upgrade cycles. Cheers, Nick. On 15 May 2014 10:09, Paul Moore p.f.mo...@gmail.com wrote: On 15 May 2014 00:03, Nick Coghlan

Re: [Distutils] Need for respect (was: PEP 438, pip and --allow-external)

2014-05-15 Thread Nick Coghlan
On 15 May 2014 20:44, Stefan Krah stefan-use...@bytereef.org wrote: Noah Kantrowitz n...@coderanger.net wrote: Coming back to PyPI: Its main purpose is having a central place to register, search for and find packages. It doesn't matter where the distribution files are hosted, as long as

Re: [Distutils] PEP 470 - Using Multi Index Support for External to PyPI Package File Hosting

2014-05-15 Thread Nick Coghlan
On 15 May 2014 21:20, Donald Stufft don...@stufft.io wrote: On May 15, 2014, at 4:16 AM, Daniele Sluijters daniele.sluijt...@gmail.com wrote: Has anyone considered what this will mean for people on distributions that ship older pip versions that can't be upgraded outside of the release

Re: [Distutils] Need for respect (was: PEP 438, pip and --allow-external)

2014-05-15 Thread Nick Coghlan
On 15 May 2014 22:05, Stefan Krah stefan-use...@bytereef.org wrote: Nick Coghlan ncogh...@gmail.com wrote: I understand you think that is the purpose of PyPI, but I'm trying to tell you that the people that work on PyPI and pip do not share this opinion, and as such it can

Re: [Distutils] PEP470, backward compat is a ...

2014-05-16 Thread Nick Coghlan
biases into the numbers is admirable, but making decisions based on numbers that are known to be inaccurate isn't a good idea either :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist

Re: [Distutils] PEP440 Version Specifier Syntax

2014-05-19 Thread Nick Coghlan
On 19 May 2014 23:44, Donald Stufft don...@stufft.io wrote: Currently PEP440 has a version specifier syntax like ``foo (2,~=2,==2,!=2,=2,=2,2,2)``. This is a hold over from PEP 345 of which I cannot locate a rationale for this change. It's at least in part to reduce ambiguity when listing

Re: [Distutils] Scripts/Entry Points Python-Version Naming

2014-05-19 Thread Nick Coghlan
On 20 May 2014 01:38, Donald Stufft don...@stufft.io wrote: If we do standardize we should also likely standardize on how we handle alternative interpreters. Things like PyPy, Jython etc. The idea of a py launcher equivalent for POSIX systems likely has a place in that discussion. As far as

Re: [Distutils] PEP440 Version Specifier Syntax

2014-05-19 Thread Nick Coghlan
On 20 May 2014 10:30, Donald Stufft don...@stufft.io wrote: Are we planning on putting these someplace where we can't unambiguously parse them? AFAIK in both the key:value form and the JSON form of the metadata are perfectly capable (and it is in fact no different processing wise) of handling

Re: [Distutils] How can we handle package renaming?

2014-05-21 Thread Nick Coghlan
On 21 May 2014 10:34, Daniel Holth dho...@gmail.com wrote: The last release of the old package should depend on the new. We also have an obsoleted by key in the new metadata iirc. Yep. The reason for doing it this way (i.e. requiring a change to the original package to indicate the

Re: [Distutils] Python installation questions

2014-05-23 Thread Nick Coghlan
On 24 May 2014 03:21, jennie.mcint...@cgsadmin.com wrote: We are interested in using Python in our environment, but I am having trouble finding the answers to a few questions. I was hoping you might be able to assist. 1) Does the latest version of Python work in the Citrix environment (and

Re: [Distutils] setup_requires and install_requires

2014-05-24 Thread Nick Coghlan
On 25 May 2014 02:54, Toby St Clere Smithe m...@tsmithe.net wrote: Daniel Holth dho...@gmail.com writes: The plan is that pip will cache builds automatically in the future. Generally build requirements should be kept separate from install requirements. This sounds like the best policy.

Re: [Distutils] setup_requires and install_requires

2014-05-25 Thread Nick Coghlan
On 25 May 2014 19:15, Toby St Clere Smithe m...@tsmithe.net wrote: Hi Nick, Nick Coghlan ncogh...@gmail.com writes: Could you let us know what your path was in looking? I thought the trail from docs.python.org - packaging.python.org - the Projects page - the respective GitHub/BitBucket pages

Re: [Distutils] setup_requires and install_requires

2014-05-25 Thread Nick Coghlan
On 25 May 2014 23:53, Toby St Clere Smithe m...@tsmithe.net wrote: Nick Coghlan ncogh...@gmail.com writes: Ah, the, distutils tracker is actually bugs.python.org, but that's not generally what people want - as you did, they want the setuptools issue tracker on BitBucket, since distutils

Re: [Distutils] pypi suggestion

2014-06-02 Thread Nick Coghlan
looking directly on PyPI. I believe there are OpenComparison based sites for some other Python subcommunities as well. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https

Re: [Distutils] PEP 470 Round 2 - Using Multi Index Support for External to PyPI Package File Hosting

2014-06-06 Thread Nick Coghlan
On 7 Jun 2014 06:08, Donald Stufft don...@stufft.io wrote: On Jun 6, 2014, at 9:41 AM, holger krekel hol...@merlinux.eu wrote: Once you care for ACLs for indexes and releases you have a number of issues to consider, it's hardly related to PEP470/PEP438. It is related, because it means

Re: [Distutils] PyPI lost IPv6 support?

2014-06-10 Thread Nick Coghlan
to the internet, PyPI is likely to be long way down the it isn't working priority list. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman

<    1   2   3   4   5   6   7   8   9   10   >