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
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
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
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
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,
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
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
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
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
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
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
,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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
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
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
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
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
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
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
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
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
), 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
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
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
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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
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
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
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
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
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
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
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
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
with
appropriately.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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
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
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
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
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
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
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
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
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
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
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
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
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
), 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
501 - 600 of 1528 matches
Mail list logo
