;t contain a
value for an argument that has a default value, then the returned
mapping won't contain that argument? If so, why not?
inspect.getcallargs works fine with default values.
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http:
al context as
> possible.
I don't really see, where this "context" can be useful. Maybe an
example would help.
> If you pass some set of arguments to the bind() method, it tries to map
> precisely that set. This way you can deduce from the BoundArguments what
> it was bound with. And default values will applied by python itself.
Anyway, I think it would be nice to be able to obtain the full
arguments mapping that the function would see, not just a subset. Of
course, we can use inspect.getcallargs for that, but I think we should
be able to do that with the new Signature API.
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov wrote:
> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>>> I'll try to answer you with the following code:
>>>
>>> >>> def foo(*args):
>>> ... print(args)
>>>
>>> >&
On Wed, Jun 6, 2012 at 10:10 PM, Yury Selivanov wrote:
> On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
>> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
>> wrote:
>>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>>>>> I'll try to answer you with t
/file/cedc68440a67/Python/bltinmodule.c#l90).
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy wrote:
> On 6/7/2012 11:45 AM, Daniel Urban wrote:
>>
>> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan
>> wrote:
>>>
>>> -* If the metaclass hint refers to an instance of ``type``, then it is
>>> +* If t
On Sat, Jun 16, 2012 at 5:56 AM, Jim J. Jewett wrote:
> I think it should be explicit that this mapping does not include
> parameters which would be filled by default arguments. In fact, if
> you stick with this interface, I would like a 3rd method that does
> fill out everything.
'].__class__
'wrapper_descriptor' is used for example the operators of built-in types:
>>> int.__dict__['__add__'].__class__
And 'method-wrapper':
>>> (5).__add__.__class__
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Hi,
when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
expensive/slow.
A simple solution is to use an in memory directory search/hash, so I was
wondering if this has been concidered in the past, if not, and I come
with a working solution for Unix (at least Linux/Freebsd)
> On Thu, 21 Jun 2012 13:17:01 +0300
> Daniel Braniss wrote:
> > Hi,
> > when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
> > expensive/slow.
> >
> > A simple solution is to use an in memory directory search/hash, so I was
> >
== 'doc'
(full changeset on
https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068)
Thanks,
Daniel Holth
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Only if it is not an OrderedDict
> query = sorted(query.items())
>
> This would not prevent breakage of unit tests, but it would make a
> much simpler fix possible: simply sort the parameters in the URL.
___
Python-Dev mailing list
Python-Dev@pyt
On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote:
> I've drafted some edits to Metadata 1.2 with valuable feedback from
...
> (full changeset on
> https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068)
Metadata 1.2 is nearly 8 years old and it's Accepted b
On Mon, Aug 27, 2012 at 4:29 PM, "Martin v. Löwis" wrote:
> Am 27.08.12 16:56, schrieb Daniel Holth:
>
>> On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote:
>>>
>>> I've drafted some edits to Metadata 1.2 with valuable feedback from
&
On Aug 28, 2012, at 1:20 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 6:29 AM, "Martin v. Löwis" wrote:
>> Am 27.08.12 16:56, schrieb Daniel Holth:
>>> Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is
>>> it better to co
On Tue, Aug 28, 2012 at 8:07 AM, Donald Stufft wrote:
> I personally think that at a minimum we should have X-Fields that
> get moved into the normal METADATA file, and personally I would
> prefer to just drop the X- prefix completely.
That is my preference as well. The standard library basically
On Tue, Aug 28, 2012 at 8:28 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft
> wrote:
>> I personally think that at a minimum we should have X-Fields that
>> get moved into the normal METADATA file, and personally I would
>> prefer to just drop the X- prefix completely.
How about
Extensions are fields that start with a pypi-registered name followed
by a hyphen. A file that contains extension fields declares them with
Extension: name :
Extension: pypiname
pypiname-Field: value
___
Python-Dev mailing list
Python-Dev@pyth
On Tue, Aug 28, 2012 at 9:09 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth wrote:
>> How about
>>
>> Extensions are fields that start with a pypi-registered name followed
>> by a hyphen. A file that contains extension fields declares t
On Tue, Aug 28, 2012 at 10:47 AM, "Martin v. Löwis" wrote:
>>> Prepare for a ten-year period of acceptance - so it
>>> would be good to be sure that no further additions are desired within
>>> the next ten years before seeking approval for the PEP.
>>
>>
>> However, this point I really don't agree
re-defines environment markers in terms of
the ast module (is there a better way to specify a subset of Python?).
The proposed Metadata 1.3 is at
https://bitbucket.org/dholth/python-peps/changeset/8fa1de7478e95b5ef3a18c3272f740d8f3e2fb80
Thanks,
Daniel Holth
On Aug 31, 2012, at 6:48 AM, "Martin v. Löwis" wrote:
> Am 31.08.12 05:16, schrieb Daniel Holth:
>> After this discussion it seemed wiser to submit my proposed 1.2 edits
>> as Metadata 1.3, adding Provides-Extra, Setup-Requires-Dist, and
>> Extension (with no
On Aug 31, 2012, at 6:54 AM, Donald Stufft wrote:
> On Friday, August 31, 2012 at 6:48 AM, "Martin v. Löwis" wrote:
>> 3. There should be a specification of how collisions between extension
>> fields and standard fields are resolved. E.g. if I have
>>
>> Extension: Home
>> Home-page: http://ww
Some edits to include / and remove rfc822 again. What is the right
email.policy.Policy()?
https://bitbucket.org/dholth/python-peps/changeset/8ec6dd453ccbde6d34c63d2d2a18393bc70cf115
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
On Fri, Aug 31, 2012 at 12:53 PM, R. David Murray wrote:
> On Fri, 31 Aug 2012 12:18:05 -0400, Daniel Holth wrote:
>> Some edits to include / and remove rfc822 again. What is the right
>> email.policy.Policy()?
>
> When I discussed using email to parse metadata with Tarek
A few more edits at
https://bitbucket.org/dholth/python-peps/diff/pep-0426.txt?diff2=058b058ee3f8&diff1=42ee0afd40ed
rfc822 is nixed in favor of 'parseable by email.parser.Parser with the
right policy'
Encoding is strictly utf-8 with the warning that older revisions have
no defined encoding (key
On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
> On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
>> “find a PEP dictator and propose changes”. And when I started the
>> thread about removing packaging in 3.3, hundreds of replies discussed
>> changing the whole distutils architecture
Add to metadata 1.3:
Description-File: README(\..+)?
Meaning the description should be read from a file in the same
directory as PKG-INFO or METADATA (including in the .dist-info
directories) and we strongly recommend it be named as README.* and be
utf-8 encoded text.
Description: is the only mu
On Fri, Sep 14, 2012 at 1:43 PM, Erik Bray wrote:
> On Fri, Sep 14, 2012 at 12:30 PM, Daniel Holth wrote:
>> Add to metadata 1.3:
>>
>> Description-File: README(\..+)?
>>
>> Meaning the description should be read from a file in the same
>> directory as
On Fri, Sep 14, 2012 at 2:03 PM, Donald Stufft wrote:
> On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote:
>
> Description: is the only multi-line field in the metadata. It is
> almost never needed at runtime. It would be great for performance and
> simplify the parser
On Sep 16, 2012, at 6:37 AM, Chris Jerdonek wrote:
> On Fri, Sep 14, 2012 at 8:12 AM, Vinay Sajip wrote:
>> I have set up a BitBucket repo called distlib, at
>>
>> https://bitbucket.org/vinay.sajip/distlib/
>>
>> ...
>>
>> The code was taken at around the time packaging was removed, and may n
> I agree with Lennart's and Antoine's advice of just move forward with what
> we have. If some PEPs need fixing then let's fix them, but we don't need to
> rock the horse even more by going overboard. Getting the sane, core bits
> into the stdlib as packaging is meant to is plenty to take on. If p
this compare to the markerlib approach? In markerlib you just
make sure all the AST nodes are in a set of allowed nodes, currently
(Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
use the normal eval(). Is one way more secure / fast / flexible than
the other?
(https://bit
> ISTM there is a space for a limited evaluator that's less limiting than
> literal_eval(). I do realise that this type of sandboxing is not easy to
> achieve,
> and I'm not aiming to advance the state of the art here - I just want to close
> the issue in the best way I can.
It is certainly a use
On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> How does this compare to the markerlib approach? In markerlib you just
>> make sure all the AST nodes are in a set of allowed nodes, currently
>> (Compare, BoolOp, Attribute, Nam
, if anything needs to
be added or revised, or, preferably, that it is awesome and you want
to use it ASAP.
Thanks,
Daniel Holth
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
Will add that the order is not significant. It is essentially a multidict.
On Thu, Oct 18, 2012 at 2:45 PM, wrote:
> I'd like to request that PEP 426 is extended to talk about the order of
> fields.
> In particular, for the Extension field, is it necessary that all "additional
> tags"
> follow i
On Thu, Oct 18, 2012 at 2:36 PM, wrote:
> ISTM that some important information and some elaboration is missing from
> PEP 425.
>
> The PEP is currently silent on how exactly these "compatibility tags" are
> combined
> with the package name, and the file extension. This should be specified, and
>
On Thu, Oct 18, 2012 at 2:21 PM, wrote:
> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use
> JSON
> Web signatures, this algorithm is not supported by the current JWS draft
> [1].
>
> Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the
> NIST P-256
On Thu, Oct 18, 2012 at 3:10 PM, Antoine Pitrou wrote:
> On Thu, 18 Oct 2012 14:35:19 -0400
> Benjamin Peterson wrote:
>> 2012/10/18 Daniel Holth :
>> > Let me know what I need to do to get it accepted, if anything needs to
>> > be added or revised, or, preferab
On Thu, Oct 18, 2012 at 3:23 PM, wrote:
>
> Zitat von Daniel Holth :
>
>
>> On Thu, Oct 18, 2012 at 2:36 PM, wrote:
>>>
>>> ISTM that some important information and some elaboration is missing from
>>> PEP 425.
>>>
>>> The PEP is
PEP: 425
Title: Compatibility Tags for Built Distributions
Version: $Revision$
Last-Modified: 07-Aug-2012
Author: Daniel Holth
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Jul-2012
Python-Version: 3.4
Post-History: 8-Aug-2012
Abstract
This PEP specifies a
PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
Discussions-To: Distutils SIG
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 Aug 2012
Abstract
This PEP describes a mechanism for adding
PEP: 427
Title: The Wheel Binary Package Format 0.1
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
Discussions-To:
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Sep-2012
Post-History:
Abstract
This PEP describes a built-package format for
Added some notes about the (lack of) ordering.
The email module provides an ordered multidict interface to the data.
The first tag wins (if you improperly define Name: twice for example),
but the order of everything is preserved. We just don't need it,
except that it might be surprising to see you
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
wrote:
> Executive summary:
>
> You probably should include a full ABNF grammar
>
> Daniel Holth writes:
>
> > To support empty lines and lines with indentation with respect to
> > the RFC 822 format
On Fri, Oct 19, 2012 at 10:20 AM, Barry Warsaw wrote:
> On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote:
>
>>The email module provides an ordered multidict interface to the data.
>>The first tag wins (if you improperly define Name: twice for example),
>>but the order of
Tweaked at http://hg.python.org/peps/rev/75474fb879d3
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
wrote:
> Executive summary:
>
> You probably should include a full ABNF grammar
The legacy PKG-INFO does not have email parse-ability. How about an
example parser implementation instea
The troublesome Description: parses fine -- as long as there is
anything but a \r\n - for example "\r\n " - on successive blank lines.
This tends to happen already.
Another solution comes to mind. Put the description in the payload.
The description can have any form, and the installer can stop par
I'm really happy with moving the troublesome Description: field to the
payload. Email Policy() is useful too.
http://hg.python.org/peps/rev/74868fe8ba17
Metadata 1.3 is a ...
+format with no maximum line length, followed by a blank line and an
+arbitrary payload. It is parseable by the ``email`
On Sun, Oct 21, 2012 at 8:27 AM, Stephen J. Turnbull wrote:
> Daniel Holth writes:
>
> > Another solution comes to mind. Put the description in the payload.
>
> That would work for me, but it would cause extensibility problems if
> anybody later found a use for other formatt
On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth wrote:
> On Thu, Oct 18, 2012 at 2:21 PM, wrote:
>> I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use
>> JSON
>> Web signatures, this algorithm is not supported by the current JWS draft
>> [1].
http://hg.python.org/peps/rev/50e8ea1a17a0
Based on the other "required" field's absence in the wild, only
"Metadata-Version", "Name", "Version", and "Summary" are required.
Hopefully a clearer explanation of 0, 1, or many occurrences of each
field.
___
On Mon, Oct 22, 2012 at 3:07 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 12:51:19 -0400
> Daniel Holth wrote:
>> On Thu, Oct 18, 2012 at 3:37 PM, Daniel Holth wrote:
>> > On Thu, Oct 18, 2012 at 2:21 PM, wrote:
>> >> I'm -1 on the usage of ed25519 in
On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou wrote:
>
> Hello,
>
> How does the pure / plat distinction as outlined in PEP 427 cope with
> Debian's system of separating installed files into pyshared (for *.py
> and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so
> files)?
>
>
On Mon, Oct 22, 2012 at 3:37 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 15:20:01 -0400
> Daniel Holth wrote:
>>
>> The decoded contents are like the JSON documents at
>> http://www.python.org/dev/peps/pep-0427/#json-web-signatures-extensions
>>
>>
On Mon, Oct 22, 2012 at 4:12 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 15:49:34 -0400
> Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 3:37 PM, Antoine Pitrou wrote:
>> > On Mon, 22 Oct 2012 15:20:01 -0400
>> > Daniel Holth wrote:
>> >>
&g
On Mon, Oct 22, 2012 at 4:13 PM, Antoine Pitrou wrote:
> On Mon, 22 Oct 2012 15:39:07 -0400
> Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 3:27 PM, Antoine Pitrou wrote:
>> >
>> > Hello,
>> >
>> > How does the pure / plat distinction as outli
On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>
> Hello,
>
> The FAQ has this weird statement:
>
> “This specification does not have an opinion on how you should organize
> your code. The .data directory is just a place for any files that are
> not normally installed inside site-packages
On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote:
> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>>
>> Hello,
>>
>> The FAQ has this weird statement:
>>
>> “This specification does not have an opinion on how you should organize
>> your
On Mon, Oct 22, 2012 at 6:20 PM, wrote:
>
> Zitat von Daniel Holth :
>
>
>> Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA?
>> Wheel's signing scheme is designed to protect against cryptography
>> that is not used. Wheel tries to
You could just include a different algorithm. He meant that the speed of
ed25519 is not an advantage in this use case. Did I mention that its c
implementation has defense against timing attacks?
On Oct 22, 2012 8:24 PM, "Stephen J. Turnbull" wrote:
> mar...@v.loewis.de writes:
>
> > Instead, the
Well, let's try again. I know Ed25519 is not on anyone's list, but I
would like to show at minimum that it is interesting.
%timeit wheel.tool.unpack('lxml-3.0.1-cp27-none-linux_x86_64.whl')
10 loops, best of 3: 123 ms per loop
.unpack() verifies the signature and extracts the file. Installation
i
On Tue, Oct 23, 2012 at 1:42 AM, wrote:
> I'm also -1 on the notion that the entire key distribution matter is out
> of scope. With that approach, I feel that the package signing is essentially
> pointless.
>
> As a general note on this, this entire issue lacks a threat model:
> what kind of att
On Tue, Oct 23, 2012 at 3:04 AM, Paul Moore wrote:
> On 22 October 2012 21:35, Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote:
>>> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>>>>
>>>> Hello,
>>>>
On Wed, Oct 24, 2012 at 7:28 AM, Ronald Oussoren wrote:
>
> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>
>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>> been stable
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren wrote:
>
> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>
>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>> been stable
I think Metadata 1.3 is done. Who would like to czar?
On Oct 22, 2012 12:53 PM, "Daniel Holth" wrote:
> http://hg.python.org/peps/rev/50e8ea1a17a0
>
> Based on the other "required" field's absence in the wild, only
> "Metadata-Version", "Name&
Now with an implementation at the end and possibly better wording for
the required fields. I think it's feature complete.
PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
Discussions-To: Distutils SIG
Status: Draft
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren wrote:
>
> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>
>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>> been stable
On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg wrote:
> On 13.11.2012 10:51, "Martin v. Löwis" wrote:
> > Am 13.11.12 03:04, schrieb Nick Coghlan:
> >> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth >> <mailto:dho...@gmail.com>> wrote:
> >>
&
Setuptools! You would avoid 75% of pypi. It is nonsense to pretend that
setuptools is not a significant packaging innovation. Its main flaw is that
it is based on distutils, a non-extensible design. distutils2 is a lot of
setuptools and distutils code with the plug-ability taken out.
Perhaps I sho
The signatures section is now just:
+If JSON web signatures are used, one or more JSON Web Signature JSON
+Serialization (JWS-JS) signatures may be stored in a file RECORD.jws
+adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256
+hash of RECORD as the JWS payload::
{ "ha
ibutors for https://bitbucket.org/dholth/pep425tags/ ? Wheel (PEP 427)
might mention that version 1.0 of the spec is only concerned with
losslessly representing existing (setuptools & distutils) packages without
trying to add too many new features apart from a standardized .egg
substitute.
distu
On Nov 14, 2012, at 2:23 AM, Ronald Oussoren wrote:
>
> On 13 Nov, 2012, at 17:21, Antoine Pitrou wrote:
>
>> Le Tue, 13 Nov 2012 16:10:30 +0100,
>> Ronald Oussoren a écrit :
>>>
>>> On 13 Nov, 2012, at 16:00, Daniel Holth wrote:
>>>>
Well, you can build eggs with Bento, and I have a patch that allows it to
build wheels, in both cases it will produce pip-compatible metadata. The
Bento author has his own informed opinions about the way packaging should
work which do not necessarily include the packaging PEPs.
___
Are you familiar with executing directories having __main__.py as python
scripts?
Daniel Holth
On Nov 15, 2012, at 4:43 PM, Christian Tismer wrote:
> Hi Kristjan,
>
> does that mean that your scheme simply works, without any config step
> necessary after I did my checkout?
>
kages. How about moving this one along to focus on
the other two.
I'm not sure what the Post-History should be. We have been talking about it
for a while.
Thanks,
Daniel Holth
PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Da
Does it really have baggage? I think it is necessary, although it doesn't do
favors to the implementer (and has never been implemented). How else is anyone
supposed to fork or merge projects?
Daniel Holth
On Nov 19, 2012, at 7:37 PM, PJ Eby wrote:
> On Mon, Nov 19, 2012 at 6:53 PM
The "I bundled a renamed copy of six" is a totally different case which would
not invoke provides-dist. "I merged sqlalchemy with a previously separate but
wildly popular declarative / database support / whatever extension" would
invoke provides-dist.
Daniel Holth
On Nov
The distro repos are centrally managed, too. Try getting setuptools to provide
a virtual package just because you want to fork.. and then update the dependent
packages?
Daniel Holth
On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote:
> Other languages seem to get along fine without it. E
We are getting along fine too. No tool parses metadata 1.x for package
management reasons and provides has existed forever with no implementation. So
it is not inconveniencing anyone. I would prefer to leave it alone.
Daniel Holth
On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote:
> Ot
> Or you do think people should implement it and the point about it existing
> forever without an implementation is?
>
> At the very least there needs to be some sort of guidelines as to what
> to do with the field in the various states it could be in.
>
> On Monday, November 19
The section could definitely be much clearer. How about:
Provides-Dist (multiple use)
Each entry contains a string naming a requirement that is satisfied by
installing this distribution. This field *must* include the project
identified in the ``Name`` field, optionally followed by the version:
N
On Tue, Nov 20, 2012 at 9:35 AM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
> > Mostly it seems a bit silly to have so much conversations about parts of
> the
> > pep that remain unchanged from previously accepted versions...
>
> I don't agree wi
On Tue, Nov 20, 2012 at 9:44 AM, Nick Coghlan wrote:
> On Tue, Nov 20, 2012 at 11:45 PM, Christian Tismer
> wrote:
>
>> On 20.11.12 12:39, Nick Coghlan wrote:
>>
>> On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson <
>> krist...@ccpgames.com> wrote:
>>
>>> I’m intrigued. I thought this
Edit the following text:
Provides-Dist (multiple use)
Each entry contains a string naming a requirement that is satisfied by
installing this distribution. This field *must* include the project
identified in the ``Name`` field, optionally followed by the version Name
(Version).
A distribution m
On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett wrote:
>
>
> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
>
> > The use of multiple names in this field *must not* be used for
> > bundling distributions together. It is intended for use when
> > projects are forked and merg
I think the Metadata 1.1 treatment of these concepts is in some ways
better. (Metadata 1.2 added the -Dist suffix to the fields in an attempt to
make it clear that dependency names are PyPI names and not "import x"
names.)
http://www.python.org/dev/peps/pep-0314/ says:
Provides (multiple use)
No. We trust the packages we install, including the way they decide to use the
metadata. A bad package could delete all our files or cause dependency
resolution to fail. Mostly they won't.
Daniel Holth
On Nov 20, 2012, at 5:26 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com
On Tue, Nov 20, 2012 at 9:44 PM, PJ Eby wrote:
> On Tue, Nov 20, 2012 at 5:01 PM, Daniel Holth wrote:
>
> http://www.python.org/dev/peps/pep-0314/ says:
>>
>> The most common use of this field will be in case a package name
>> changes, e.g. Gorgon 2.3
On Tue, Nov 20, 2012 at 7:18 PM, Jim Jewett wrote:
> On 11/20/12, Daniel Holth wrote:
> > On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett
> > wrote:
>
> >> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
>
> >> > The us
How to use Obsoletes:
The author of B decides A is obsolete.
A releases an empty version of itself that Requires: B
B Obsoletes: A
The package manager says "These packages are obsolete: A". Would you like
to remove them?
User says "OK".
On Wed, Nov 21, 2012 at 2:54 AM, Stephen J. Turnbull wr
t;,
> I think I'm inclined to agree with you, as "Obsoleted-By" provides a way
> for a maintainer to explicitly declare that a project is no longer
> receiving updates, and users should migrate to the replacement project if
> they want to continue to receive fixes and im
On Wed, Dec 5, 2012 at 4:10 PM, PJ Eby wrote:
> On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft
> wrote:
> > There's nothing preventing an installer from, during it's attempt to
> > install B, see it Obsoletes A, looking at what depends on A and
> > warning the user what is going to happen and pro
Makes sense. How about calling it Replacement. 0 or 1?
Replacement (optional)
::
Indicates that this project is no longer being developed. The named
project provides a drop-in replacement.
A version declaration may be supplied and must follow the rules described
in `Version
On Thu, Dec 6, 2012 at 6:33 AM, Donald Stufft wrote:
> On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
>
> Donald Stufft gmail.com> writes:
>
> Never mind the "Obsoletes" information - even the more useful
> "Requires-Dist"
> information is not exposed via PyPI, even though it appear
On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
> > The wheel implementation makes sure all the metadata (the .dist-info
> directory)
> > is at the end of the .zip archive. It's possible to read the metadata
> with a
> &g
On Thu, Dec 6, 2012 at 11:30 AM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
> > You have to make a maximum of 3 requests: one for the directory pointer,
> one
> > for the directory, and one for the file you want. It's not particularly
> > diffic
On Mon, Dec 10, 2012 at 2:22 AM, Antonio Cavallo wrote:
> Hi,
> I wonder if is it worth/if there is any interest in trying to "clean" up
> distutils: nothing in terms to add new features, just a *major* cleanup
> retaining the exact same interface.
>
>
> I'm not planning anything like *adding feat
401 - 500 of 590 matches
Mail list logo
