Some further analysis of the problem:
Mercurial is (and should be) installed system-wide.
The 'hg' command (at least my homebrew install) uses the normal shebang
line
#!/usr/bin/env python
When using virtualenv and python2.7, this works fine.
When using virtualenv or venv and python3.3, then
I've decided I'm really not happy with the current approach to
extension fields in PEP 426. It's ugly, clunky, inflexible and is hard
to cleanly convert to more structured metadata.
Here's the current example from the PEP:
Extension: Chili
Chili/Type: Poblano
Chili/Heat: Mild
Here's
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
Key: value format. The METADATA file needs to represent Name, Version, and
Requirements and the rest is fluff that no one will ever use. It's very
(This probably belongs in a successor to PEP 376, but I'll leave it
under the PEP 426 umbrella for now)
One of the points raised regarding PEP 426's integrated metadata
format is the potential for runtime issues with pkg_resources as it
reads and processes the metadata during startup,
On 25 February 2013 14:39, Nick Coghlan ncogh...@gmail.com wrote:
(This probably belongs in a successor to PEP 376, but I'll leave it
under the PEP 426 umbrella for now)
One of the points raised regarding PEP 426's integrated metadata
format is the potential for runtime issues with
Addendum (see the end)
On 25.02.13 13:27, Christian Tismer wrote:
Some further analysis of the problem:
Mercurial is (and should be) installed system-wide.
The 'hg' command (at least my homebrew install) uses the normal shebang
line
#!/usr/bin/env python
When using virtualenv and python2.7,
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
Key: value format.
I don't really care that much about human readability of
On Tue, Feb 26, 2013 at 12:45 AM, Paul Moore p.f.mo...@gmail.com wrote:
We don't really need everything to be in a single file, surely?
Yes, I want the metadata to map cleanly to a single data structure so
it can be more easily managed through things that *aren't* file
systems (such as finally
On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
On Tue, Feb 26, 2013 at 12:59 AM, Daniel Holth dho...@gmail.com wrote:
On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks
On Tue, Feb 26, 2013 at 1:29 AM, Daniel Holth dho...@gmail.com wrote:
Well this is a rabbit hole. setup.cfg is what you get when the metadata
devolves into the arguments passed to setup(). Perhaps that is the real
reason I don't like JSON that much; the temptation would be to make it
nothing
Hi Christian,
On 02/25/2013 05:27 AM, Christian Tismer wrote:
Some further analysis of the problem:
Mercurial is (and should be) installed system-wide.
The 'hg' command (at least my homebrew install) uses the normal shebang
line
#!/usr/bin/env python
When using virtualenv and
Hi Christian,
On 02/25/2013 07:48 AM, Christian Tismer wrote:
After looking into pip help install, I tried to run
(venv) $ pip install mercurial --install-option=--c2to3
Yes, this should be the correct way to pass an option directly to
Mercurial's setup.py.
Now the crazy effect is:
Post install hooks are different than setup.py because they are installed
first and then run for all packages, and are not requested by the installed
dist. They are more like rewriting script #!python shebang.
May I humbly suggest deleting things from this pep until it is acceptable
and not the
Nick Coghlan ncoghlan at gmail.com writes:
The other area where I think such an embedded JSON approach could
work is coming up with a clean format for an Entry-Points field.
Specifically, I am thinking of proposing the setuptools.setup
inspired:
Entry-Points: {
I can accept a rename but there is no way to avoid having 2 names not 1 new
name for the feature.
We go halfway now. The next version can go any other way.
On Feb 25, 2013 12:23 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
The other area where I
Hi Carl,
On 25.02.13 17:47, Carl Meyer wrote:
Hi Christian,
On 02/25/2013 05:27 AM, Christian Tismer wrote:
Some further analysis of the problem:
...
But actually, the bad thing IMHO is the naming clash introduced by the
symlinks that v(irtual)env is setting:
Why does it ignore the
Daniel Holth dholth at gmail.com writes:
I can accept a rename but there is no way to avoid having 2 names not 1 new
name for the feature.
We go halfway now. The next version can go any other way.
Just to be clear, the naming of exports vs. entry points was not the main
thrust of my point -
On 02/25/2013 10:31 AM, Christian Tismer wrote:
Actually, I would love to have both python2 and python3 in the same
virtualenv, for testing purposes, distinguishing the versions by using
the different interpreter, only.
But installing both versions after another messes things up very much
and
Hi Carl,
On 25.02.13 18:38, Carl Meyer wrote:
On 02/25/2013 10:31 AM, Christian Tismer wrote:
Actually, I would love to have both python2 and python3 in the same
virtualenv, for testing purposes, distinguishing the versions by using
the different interpreter, only.
But installing both versions
With all the talk about pyladies etc. I wondered: are you female and
working on Python packaging? Poll at http://strawpoll.me/7874
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 02/23/2013 08:08 PM, Nick Coghlan wrote:
On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote:
There simply must be a way to spell equals that means equals. It will be
used when that so-called security release broke my application that
integrates said library in a way that
Daniel Holth dholth at gmail.com writes:
We all must realize that incremental improvements are not harmful. Delay is
harmful; there has been no obvious way to make a Python package this decade
based on the idea that something better might be just around the corner or that
the current way will be
We have a potential solution from node which is to allow limited globs in
version matches 1.0.*
On Feb 25, 2013 3:04 PM, Carl Meyer c...@oddbird.net wrote:
On 02/23/2013 08:08 PM, Nick Coghlan wrote:
On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote:
There simply must be a
All I'm trying to say is do not add anything else to pep 426. There will be
other versions. This version can be consumed by distutils as of last July.
Daniel Holth dholth at gmail.com writes:
We all must realize that incremental improvements are not harmful. Delay
is
harmful; there has been no
by which I mean distribute
On Feb 25, 2013 5:55 PM, Daniel Holth dho...@gmail.com wrote:
All I'm trying to say is do not add anything else to pep 426. There will
be other versions. This version can be consumed by distutils as of last
July.
Daniel Holth dholth at gmail.com writes:
We all
I realised globbing won't work easily, due to alpha/beta/release candidates
missing the preceding dot, so 1.1.1.* wouldn't match versions like 1.1.1c1,
while leaving the dot out would mean 1.1.1* matching versions like 1.1.11
(it also means the old PEP 345 default behaviour and the current ==
On Saturday, February 23, 2013 at 10:08 PM, Nick Coghlan wrote:
The core problem with making == strict is that it either makes !=
useless by allowing (!=1.3) to match 1.3.1, or it breaks the
invariant that != is the logical inverse of ==, by having both
(==1.3) and (!=1.3) reject 1.3.1. I
On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com wrote:
!=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0, 1.3.1 !=
1.3.0.
Nope, the PEP explicitly disclaims the historical equivalence between
1.3 and 1.3.0. It has to, because they're very different when
29 matches
Mail list logo
