Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

Another hopefully last tweak - adding in more punctuation to the
strings in markers. I'm still holding off of defining \ escapes for
now.

-Rob

diff --git a/dependency-specification.rst b/dependency-specification.rst
index 8a632ba..b115b66 100644
--- a/dependency-specification.rst
+++ b/dependency-specification.rst
@@ -96,7 +96,9 @@ environments::

 marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
 python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
- '-' | '_' | '*')
+ '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' |
+ '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' |
+ '&' | '=' | '+' | '|' | '<' | '>' )
 dquote= '"'
 squote= '\\''
 python_str= (squote (python_str_c | dquote)* squote |
@@ -361,7 +363,9 @@ The complete parsley grammar::
 urlspec   = '@' wsp* 
 marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
 python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
- '-' | '_' | '*' | '#')
+ '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' |
+ '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' |
+ '&' | '=' | '+' | '|' | '<' | '>' )
 dquote= '"'
 squote= '\\''
 python_str= (squote <(python_str_c | dquote)*>:s squote |

On 18 November 2015 at 09:51, Robert Collins  wrote:
> Addressed along with some minor quirks and github feedback.
>
> diff --git a/dependency-specification.rst b/dependency-specification.rst
> index a9953ed..8a632ba 100644
> --- a/dependency-specification.rst
> +++ b/dependency-specification.rst
> @@ -18,7 +18,7 @@ Abstract
>  This PEP specifies the language used to describe dependencies for packages.
>  It draws a border at the edge of describing a single dependency - the
>  different sorts of dependencies and when they should be installed is a higher
> -level problem. The intent is provide a building block for higher layer
> +level problem. The intent is to provide a building block for higher layer
>  specifications.
>
>  The job of a dependency is to enable tools like pip [#pip]_ to find the right
> @@ -85,7 +85,7 @@ Versions may be specified according to the PEP-440
> [#pep440]_ rules. (Note:
>  URI is defined in std-66 [#std66]_::
>
>  version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
> -version   = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' )+
> +version   = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' 
> )+
>  version_one   = version_cmp version wsp*
>  version_many  = version_one (wsp* ',' version_one)*
>  versionspec   = ( '(' version_many ')' ) | version_many
> @@ -94,7 +94,7 @@ URI is defined in std-66 [#std66]_::
>  Environment markers allow making a specification only take effect in some
>  environments::
>
> -marker_op = version_cmp | 'in' | 'not' wsp+ 'in'
> +marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
>  python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
>   '-' | '_' | '*')
>  dquote= '"'
> @@ -108,10 +108,14 @@ environments::
>   'implementation_name' | 'implementation_version' |
>   'extra' # ONLY when defined by a containing layer
>   )
> -marker_var= env_var | python_str
> -marker_expr   = ('(' wsp* marker wsp* ')'
> - | (marker_var wsp* marker_op wsp* marker_var))
> -marker= wsp* marker_expr ( wsp* ('and' | 'or') wsp* marker_expr)*
> +marker_var= wsp* (env_var | python_str)
> +marker_expr   = marker_var marker_op marker_var
> +  | wsp* '(' marker wsp* ')'
> +marker_and= marker_expr wsp* 'and' marker_expr
> +  | marker_expr
> +marker_or = marker_and wsp* 'or' marker_and
> +  | marker_and
> +marker= marker_or
>  quoted_marker = ';' wsp* marker
>
>  Optional components of a distribution may be specified using the extras
> @@ -304,7 +308,7 @@ The ``implementation_version`` marker variable is
> derived from
>  Backwards Compatibility
>  ===
>
> -Most of this PEP is already widely deployed and thus offers no compatibiltiy
> +Most of this PEP is already widely deployed and thus offers no compatibility
>  concerns.
>
>  There are however a few points where the PEP differs from the deployed base.
> @@ -355,7 +359,7 @@ The complete parsley grammar::
>  version_many  = version_one:v1 (wsp* ',' version_one)*:v2 -> [v1] + v2
>  versionspec   = ('(' version_many:v ')' ->v) | version_many
>  urlspec   = '@' wsp* 
> -marker_op = version_cmp | 'in' | 'not' wsp+ 'in'
> +marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
>  python_str_c  = (wsp

Re: [Distutils] Packaging shared objects with setuptools

[Erik Bray]

On Fri, Oct 30, 2015 at 12:47 PM, Mario Pezzoni  wrote:
> Hello,
>
> I am wrapping a c++ library with cython. I compile the pyxs and the c++ code
> with cmake using the cython-cmake-example.
> If I import the package from the build directory it works flawlessly, if I
> install through "python setup.py install" into a virtual environment it
> breaks because the shared objects are not installed (but all the pure .py
> modules are installed).
>
> How do I tell setuptools to install the shared objects?

For starters, what does your setup.py look like?  You should make sure
all extension modules are registered with setup() as described here:

https://docs.python.org/2/distutils/examples.html#single-extension-module

I'm not sure what cython-cmake-example is though, or how whatever it
does would interact with distutils.

Erik
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 10:22, R. David Murray  wrote:
...
>> As I understand it, you and Antoine are saying that the current PEP
>> *does* define implementation because folk can't trust their URI
>> library to error appropriately - and thats the bit I don't understand.
>> Just parse however you want as an author, and cross check against the
>> full grammar here in case of doubt.
>
> OK, so it *is* the case that the PEP is mandating that a conforming
> implementation has to accept valid and reject invalid URLs according
> to the grammar in the PEP, but not *how* or *when* it does that (the
> implementation).  So "trap malformed URLs early" is false, but "trap
> malformed URLs" is true, if you want to be a conformant implementation.

Yes.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[R. David Murray]

On Wed, 18 Nov 2015 09:02:31 +1300, Robert Collins  
wrote:
> On 18 November 2015 at 08:53, Paul Moore  wrote:
> > On 17 November 2015 at 18:43, Robert Collins  
> > wrote:
> >>> By including the URL syntax, we're mandating that conforming
> >>> implementations *have* to trap malformed URLs early, and can't defer
> >>> that validation to the URL library being used to process the URL.
> >>
> >> I don't understand how we're mandating that.
> >
> > urlspec   = '@' wsp* 
> >
> > combined with
> >
> >  URI_reference = 
> >  URI   = scheme ':' hier_part ('?' query )? ( '#' fragment)?
> > (etc)
> >
> > implies that conforming parsers have to validate that what follows '@'
> > must conform to the URI definition. So they have to reject @:
> > because : is not a valid URI. But why bother? It's extra work, and
> > given that all an implementation will ever do with the URI_reference
> > is pass it to a function that treats it as a URI, and that function
> > will do all the validation you need.
> >
> > I'd argue that the spec can simply say
> >
> > URI_reference = 
> >
> > The discussion of how a urlspec is used can point out that the string
> > will be assumed to be a URI.
> >
> > A library that parsed any non-whitespace string as a URI_reference
> > would be just as useful for all practical purposes, and much easier to
> > write (and test!) But it would technically be non-conformant to this
> > PEP.
> >
> > Personally, I don't actually care all that much, as I probably won't
> > ever write a library that implements this spec. The packaging library
> > will be fine for me. But given that the point of writing the
> > interoperability PEPs is to ensure people *can* write alternative
> > implementations, I'm against adding complexity and implementation
> > burden that has no practical benefit.
> 
> 
> I'm still struggling to understand.
> 
> I see two angles; the first is on what is accepted or not by an 
> implementation:
> The reference here is not the implementation - its a *reference*. An
> implementation whose URI handling can't handle std-66 URI's that
> another ones can would lead to interop issues : and thats what we're
> trying to avoid. An alternative implementation whose URI handling has
> some extension that means it handles things that other implementations
> don't would accept everything the PEP mandates but also accept more -
> leading to interop issues. Some interop issues (e.g. pip handles
> git+https:// urls, setuptools doesn't) are not covered yet, but thats
> a pep-440 issue (at least, the way things are split up today) - so I
> don't want to dive into that.
> 
> The second is on whether the implementation achieves that acceptance
> up front in its parsing, or on the backend in its URI library. And I
> could care way less which way around it does it. We're not defining
> implementation, but we are defining the language.
> 
> As I understand it, you and Antoine are saying that the current PEP
> *does* define implementation because folk can't trust their URI
> library to error appropriately - and thats the bit I don't understand.
> Just parse however you want as an author, and cross check against the
> full grammar here in case of doubt.

OK, so it *is* the case that the PEP is mandating that a conforming
implementation has to accept valid and reject invalid URLs according
to the grammar in the PEP, but not *how* or *when* it does that (the
implementation).  So "trap malformed URLs early" is false, but "trap
malformed URLs" is true, if you want to be a conformant implementation.

--David
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Robert Collins]

On 18 November 2015 at 04:20, Daniel Holth  wrote:
> LGTM
>
> Q: Why is build_command a list?

I misread the question - fixed.

diff --git a/build-system-abstraction.rst b/build-system-abstraction.rst
index 8eb0681..d36b7d5 100644
--- a/build-system-abstraction.rst
+++ b/build-system-abstraction.rst
@@ -91,7 +91,7 @@ build_command
 A mandatory Python format string [#strformat]_ describing the command to
 run. For instance, if using flit then the build command might be::

-build_command: ["flit"]
+build_command: "flit"

 If using a command which is a runnable module fred::

@@ -254,7 +254,7 @@ Examples
 An example 'pypa.json' for using flit::

   {"bootstrap_requires": ["flit"],
-   "build_command": ["flit"]}
+   "build_command": "flit"}

 When 'pip' reads this it would prepare an environment with flit in it before
 trying to use flit.

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

Addressed along with some minor quirks and github feedback.

diff --git a/dependency-specification.rst b/dependency-specification.rst
index a9953ed..8a632ba 100644
--- a/dependency-specification.rst
+++ b/dependency-specification.rst
@@ -18,7 +18,7 @@ Abstract
 This PEP specifies the language used to describe dependencies for packages.
 It draws a border at the edge of describing a single dependency - the
 different sorts of dependencies and when they should be installed is a higher
-level problem. The intent is provide a building block for higher layer
+level problem. The intent is to provide a building block for higher layer
 specifications.

 The job of a dependency is to enable tools like pip [#pip]_ to find the right
@@ -85,7 +85,7 @@ Versions may be specified according to the PEP-440
[#pep440]_ rules. (Note:
 URI is defined in std-66 [#std66]_::

 version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
-version   = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' )+
+version   = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+
 version_one   = version_cmp version wsp*
 version_many  = version_one (wsp* ',' version_one)*
 versionspec   = ( '(' version_many ')' ) | version_many
@@ -94,7 +94,7 @@ URI is defined in std-66 [#std66]_::
 Environment markers allow making a specification only take effect in some
 environments::

-marker_op = version_cmp | 'in' | 'not' wsp+ 'in'
+marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
 python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
  '-' | '_' | '*')
 dquote= '"'
@@ -108,10 +108,14 @@ environments::
  'implementation_name' | 'implementation_version' |
  'extra' # ONLY when defined by a containing layer
  )
-marker_var= env_var | python_str
-marker_expr   = ('(' wsp* marker wsp* ')'
- | (marker_var wsp* marker_op wsp* marker_var))
-marker= wsp* marker_expr ( wsp* ('and' | 'or') wsp* marker_expr)*
+marker_var= wsp* (env_var | python_str)
+marker_expr   = marker_var marker_op marker_var
+  | wsp* '(' marker wsp* ')'
+marker_and= marker_expr wsp* 'and' marker_expr
+  | marker_expr
+marker_or = marker_and wsp* 'or' marker_and
+  | marker_and
+marker= marker_or
 quoted_marker = ';' wsp* marker

 Optional components of a distribution may be specified using the extras
@@ -304,7 +308,7 @@ The ``implementation_version`` marker variable is
derived from
 Backwards Compatibility
 ===

-Most of this PEP is already widely deployed and thus offers no compatibiltiy
+Most of this PEP is already widely deployed and thus offers no compatibility
 concerns.

 There are however a few points where the PEP differs from the deployed base.
@@ -355,7 +359,7 @@ The complete parsley grammar::
 version_many  = version_one:v1 (wsp* ',' version_one)*:v2 -> [v1] + v2
 versionspec   = ('(' version_many:v ')' ->v) | version_many
 urlspec   = '@' wsp* 
-marker_op = version_cmp | 'in' | 'not' wsp+ 'in'
+marker_op = version_cmp | (wsp* 'in') | (wsp* 'not' wsp+ 'in')
 python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
  '-' | '_' | '*' | '#')
 dquote= '"'
@@ -369,12 +373,14 @@ The complete parsley grammar::
  'implementation_name' | 'implementation_version' |
  'extra' # ONLY when defined by a containing layer
  ):varname -> lookup(varname)
-marker_var= env_var | python_str
-marker_expr   = (("(" wsp* marker:m wsp* ")" -> m)
- | ((marker_var:l wsp* marker_op:o wsp* marker_var:r))
- -> (l, o, r))
-marker= (wsp* marker_expr:m ( wsp* ("and" | "or"):o wsp*
- marker_expr:r -> (o, r))*:ms -> (m, ms))
+marker_var= wsp* (env_var | python_str)
+marker_expr   = marker_var:l marker_op:o marker_var:r -> (o, l, r)
+  | wsp* '(' marker:m wsp* ')' -> m
+marker_and= marker_expr:l wsp* 'and' marker_expr:r -> ('and', l, r)
+  | marker_expr:m -> m
+marker_or = marker_and:l wsp* 'or' marker_and:r -> ('or', l, r)
+  | marker_and:m -> m
+marker= marker_or
 quoted_marker = ';' wsp* marker
 identifier= =3,<2",
 "name [fred,bar] @ http://foo.com ; python_version=='2.7'",
 "name[quux, strange];python_version<'2.7' and platform_version=='2'",
-"name; os_name=='dud' and (os_name=='odd' or os_name=='fred')",
-"name; os_name=='dud' and os_name=='odd' or os_name=='fred'",
+"name; os_name=='a' or os_name=='b'",
+# Should parse as (a and b) or c
+"name; os_name=='a' and os_name=='b' or os

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Paul Moore]

On 17 November 2015 at 20:02, Robert Collins  wrote:
> As I understand it, you and Antoine are saying that the current PEP
> *does* define implementation because folk can't trust their URI
> library to error appropriately - and thats the bit I don't understand.
> Just parse however you want as an author, and cross check against the
> full grammar here in case of doubt.

What I'm saying is that for syntax, a conforming implementation has to
stand alone in its conformance to the spec. If the spec says X is
(in)valid, then the implementation should agree. I might want to use
the implementation to *check* that some file conforms to the spec, so
I may not even be using a URL library.

On the other hand, *semantics* are how you use the data - it's
perfectly OK to say that the "urlspec" chunk of data is intended to be
passed to a URL library. In that case, @::: is valid (it conforms to
the syntax) but meaningless. That's a looser spec (and so easier to
implement) but just as useful in any practical sense.

One last point - AIUI, the implementation being added to the packaging
library does full URI parsing. And I doubt anyone claiming to be
implementing the spec would feel comfortable not doing so. So I don't
follow your idea that people implementing the spec can defer to a URL
library for that bit - it's not what's actually happening.

Anyway, as I said it's not going to affect me in practice, so I'll
leave it here. Ultimately it'll be for the BDFL-delegate for this PEP
to decide whether it's worth asking for a change in this area.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 08:53, Paul Moore  wrote:
> On 17 November 2015 at 18:43, Robert Collins  
> wrote:
>>> By including the URL syntax, we're mandating that conforming
>>> implementations *have* to trap malformed URLs early, and can't defer
>>> that validation to the URL library being used to process the URL.
>>
>> I don't understand how we're mandating that.
>
> urlspec   = '@' wsp* 
>
> combined with
>
>  URI_reference = 
>  URI   = scheme ':' hier_part ('?' query )? ( '#' fragment)?
> (etc)
>
> implies that conforming parsers have to validate that what follows '@'
> must conform to the URI definition. So they have to reject @:
> because : is not a valid URI. But why bother? It's extra work, and
> given that all an implementation will ever do with the URI_reference
> is pass it to a function that treats it as a URI, and that function
> will do all the validation you need.
>
> I'd argue that the spec can simply say
>
> URI_reference = 
>
> The discussion of how a urlspec is used can point out that the string
> will be assumed to be a URI.
>
> A library that parsed any non-whitespace string as a URI_reference
> would be just as useful for all practical purposes, and much easier to
> write (and test!) But it would technically be non-conformant to this
> PEP.
>
> Personally, I don't actually care all that much, as I probably won't
> ever write a library that implements this spec. The packaging library
> will be fine for me. But given that the point of writing the
> interoperability PEPs is to ensure people *can* write alternative
> implementations, I'm against adding complexity and implementation
> burden that has no practical benefit.


I'm still struggling to understand.

I see two angles; the first is on what is accepted or not by an implementation:
The reference here is not the implementation - its a *reference*. An
implementation whose URI handling can't handle std-66 URI's that
another ones can would lead to interop issues : and thats what we're
trying to avoid. An alternative implementation whose URI handling has
some extension that means it handles things that other implementations
don't would accept everything the PEP mandates but also accept more -
leading to interop issues. Some interop issues (e.g. pip handles
git+https:// urls, setuptools doesn't) are not covered yet, but thats
a pep-440 issue (at least, the way things are split up today) - so I
don't want to dive into that.

The second is on whether the implementation achieves that acceptance
up front in its parsing, or on the backend in its URI library. And I
could care way less which way around it does it. We're not defining
implementation, but we are defining the language.

As I understand it, you and Antoine are saying that the current PEP
*does* define implementation because folk can't trust their URI
library to error appropriately - and thats the bit I don't understand.
Just parse however you want as an author, and cross check against the
full grammar here in case of doubt.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Paul Moore]

On 17 November 2015 at 18:43, Robert Collins  wrote:
>> By including the URL syntax, we're mandating that conforming
>> implementations *have* to trap malformed URLs early, and can't defer
>> that validation to the URL library being used to process the URL.
>
> I don't understand how we're mandating that.

urlspec   = '@' wsp* 

combined with

 URI_reference = 
 URI   = scheme ':' hier_part ('?' query )? ( '#' fragment)?
(etc)

implies that conforming parsers have to validate that what follows '@'
must conform to the URI definition. So they have to reject @:
because : is not a valid URI. But why bother? It's extra work, and
given that all an implementation will ever do with the URI_reference
is pass it to a function that treats it as a URI, and that function
will do all the validation you need.

I'd argue that the spec can simply say

URI_reference = 

The discussion of how a urlspec is used can point out that the string
will be assumed to be a URI.

A library that parsed any non-whitespace string as a URI_reference
would be just as useful for all practical purposes, and much easier to
write (and test!) But it would technically be non-conformant to this
PEP.

Personally, I don't actually care all that much, as I probably won't
ever write a library that implements this spec. The packaging library
will be fine for me. But given that the point of writing the
interoperability PEPs is to ensure people *can* write alternative
implementations, I'm against adding complexity and implementation
burden that has no practical benefit.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 00:26, Thomas Güttler
 wrote:
..
> I want to parse a single dependency of a python
> package.

Presumably from Python; in which case you can use the packaging
library once the PEP is pronounced on and the code has been added.

If you want to do it from another language, you can use the grammar
from the PEP to write an implementation.

Please do remember though, the *goal* of the PEP process here is to
define the interoperation of multiple competing implementations. So
its actually the intent that you be able to write a library function
from this specification and have good confidence that it will
interoperate with the one in pip - *whether or not that is in / from a
library*.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 07:10, Paul Moore  wrote:
> On 17 November 2015 at 17:32, Robert Collins  
> wrote:
>>> The only place where URIs are used seem to be the "urlspec" rule, and
>>> probably you can accept any opaque string there.
>>
>> Uhm, why are you making this suggestion? What problem will we solve by
>> using a proxy rule?
>
> I think the point here is syntax vs semantics. It is simpler to parse
> if we make the *syntax* state that an opaque string is allowed here.
> The *semantics* can then say that the string is to be handled as a
> URL, meaning that any string that isn't a valid URL will fail when we
> try to pass it to urllib or whatever.
>
> The only advantage of *parsing* it as a URL is that we get to reject
> foo/bar:baz as a syntax error. But we'd still reject foo:/bar as
> an invalid URL (unknown protocol) later in the processing, so why
> bother trying to trap the specific error of "doesn't look like a URL"
> early?
>
> By including the URL syntax, we're mandating that conforming
> implementations *have* to trap malformed URLs early, and can't defer
> that validation to the URL library being used to process the URL.

I don't understand how we're mandating that.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Link to lib missing in PEP: FINAL DRAFT: Dependency specifier PEP

[Thomas Güttler]

Am 17.11.2015 um 15:13 schrieb Ronny Pfannschmidt:
> That is no acceptable way to answer in particular since the original mail 
> continued with places where to put the link

I was asking for a link from the PEP to the implementation.

I received a "no".

I replyed with my opinion.

What is not acceptable?

Regards,
  Thomas Güttler



-- 
http://www.thomas-guettler.de/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Paul Moore]

On 17 November 2015 at 17:32, Robert Collins  wrote:
>> The only place where URIs are used seem to be the "urlspec" rule, and
>> probably you can accept any opaque string there.
>
> Uhm, why are you making this suggestion? What problem will we solve by
> using a proxy rule?

I think the point here is syntax vs semantics. It is simpler to parse
if we make the *syntax* state that an opaque string is allowed here.
The *semantics* can then say that the string is to be handled as a
URL, meaning that any string that isn't a valid URL will fail when we
try to pass it to urllib or whatever.

The only advantage of *parsing* it as a URL is that we get to reject
foo/bar:baz as a syntax error. But we'd still reject foo:/bar as
an invalid URL (unknown protocol) later in the processing, so why
bother trying to trap the specific error of "doesn't look like a URL"
early?

By including the URL syntax, we're mandating that conforming
implementations *have* to trap malformed URLs early, and can't defer
that validation to the URL library being used to process the URL.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Antoine Pitrou]

On Wed, 18 Nov 2015 06:47:53 +1300
Robert Collins  wrote:
> Note that previous PEPs have either had no grammar (and
> interop issue) or partially defined grammar's (and logical issues -
> see PEP-426 for example). I think its very important we be able to
> test what we're saying should happen well.

Of course. But only for the things the PEP is useful for: i.e.,
packaging-related information. Being able to separate valid URIs and
invalid URIs is not a useful feature for an implementation of this PEP.
Yet (correct me if I'm wrong) you seem to claim it's an integral part of
being a conformant implementation.

> Implementations don't have to use the grammar, they just have to
> accept the same inputs

It means they have to invoke some logic to reject invalid URIs upfront,
even though it's none of their business (since they will later treat
the URIs as strings, anyway).

> packaging's
> implementation doesn't use the same grammar, for instance. (It uses
> pyparsing and a mix of regexes and objects).

And the URI validation bit is implemented as...?

> Since the bit you're complaining about is basically an appendix, I can
> see that it makes the PEP shorter, but not how it makes it simpler: we
> still depend on the definition of URI, because we consume URI's

"We" don't depend on it. Whatever does the URI parsing and loading does
- another library certainly, not a packaging-specific library. From a
packaging point of view, URIs are plain strings, not something you
parse to extract meaningful information.  This is called abstraction :-)

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 06:35, Antoine Pitrou  wrote:
> On Wed, 18 Nov 2015 06:32:35 +1300
> Robert Collins  wrote:
>> >
>> > The only place where URIs are used seem to be the "urlspec" rule, and
>> > probably you can accept any opaque string there.
>>
>> Uhm, why are you making this suggestion? What problem will we solve by
>> using a proxy rule?
>
> Making the PEP simpler, making implementations simpler, avoiding bugs
> in implementations which may otherwise try to implement full URI
> matching, avoiding having to issue a PEP update whenever the IETF
> updates the definition.
>
> These are the four I can think about, anyway :-)

Taking them in reverse order:
We reference the URI standard, so when that changes, our definition
changes - we can update the combined grammar, but we don't need to
update anything we've defined (unless the URI change is something that
invalidates our symbol delimitation, in which case we'd have to
anyway.

The grammar is a reference, meant to act as a test in the event of
disagreement should two implementations differ from each other. The
packaging implementation for instance uses pyparsing and thus by
necessity a different grammar. Implementations don't have to use any
of it - I'm not sure, unless we require that implementations use
OMeta, how we're causing (or preventing) bugs by changing the combined
grammar. Note that previous PEPs have either had no grammar (and
interop issue) or partially defined grammar's (and logical issues -
see PEP-426 for example). I think its very important we be able to
test what we're saying should happen well.

Implementations don't have to use the grammar, they just have to
accept the same inputs and interpret it in the same ways. packaging's
implementation doesn't use the same grammar, for instance. (It uses
pyparsing and a mix of regexes and objects).

Since the bit you're complaining about is basically an appendix, I can
see that it makes the PEP shorter, but not how it makes it simpler: we
still depend on the definition of URI, because we consume URI's - and
thats a PEP-440 choice, so changing that is something I'd seek a very
strong reason for, since its accepted.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Robert Collins]

On 18 November 2015 at 05:28, Leonardo Rochael Almeida
 wrote:
> On 17 November 2015 at 13:20, Daniel Holth  wrote:
>>
>> LGTM
>>
>> Q: Why is build_command a list?
>> Q: Why isn't the file name venezuelanbeavercheese.json instead of
>> pypa.json?
>
>
> Or why not just use a specific key in setup.cfg instead of a pypa.json file?
> ISTM that this PEP expects to find in pypa.json some keys that are supposed
> to be entered manually by humans, even though json is a format more easily
> written by machines than by humans...

I believe this is fully described in the rationale section - if not,
let me know which bit didn't make sense and I'll edit it.

-Rob
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Robert Collins]

On 18 November 2015 at 04:20, Daniel Holth  wrote:
> LGTM
>
> Q: Why is build_command a list?

Because the dependency spec framing we established doesn't describe
multiple dependencies in one string (and we chose to write one that
can be embedded in different higher layer things specifically to allow
wider reuse) - we could define a wrapper here, or, since we have a
structured config file, use that structure. It read a bit nicer in
YAML, but see JSON under rationale.

> Q: Why isn't the file name venezuelanbeavercheese.json instead of pypa.json?

:)

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Antoine Pitrou]

On Wed, 18 Nov 2015 06:32:35 +1300
Robert Collins  wrote:
> >
> > The only place where URIs are used seem to be the "urlspec" rule, and
> > probably you can accept any opaque string there.
> 
> Uhm, why are you making this suggestion? What problem will we solve by
> using a proxy rule?

Making the PEP simpler, making implementations simpler, avoiding bugs
in implementations which may otherwise try to implement full URI
matching, avoiding having to issue a PEP update whenever the IETF
updates the definition.

These are the four I can think about, anyway :-)

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Robert Collins]

On 18 November 2015 at 03:27, Antoine Pitrou  wrote:
> On Tue, 17 Nov 2015 15:24:04 +1300
> Robert Collins  wrote:
>>
>> The programmatic interface allows decoupling of pip from its current
>> hard dependency on setuptools [#setuptools]_ able for two
>> key reasons:
>>
>> 1. It enables new build systems that may be much easier to use without
>>requiring them to even appear to be setuptools.
>
> And yet:
>
>> There are a number of separate subcommands that build systems must support.
>
> I wonder how desirable and viable this all is. Desirable, because you
> are still asking the build system to appear as setuptools *in some way*.
> Viable, because pip may some day need to ask more from setuptools and
> then third-party build tools will have to adapt and implement said
> command-line options, defeating the "abstraction".
>
> In other words, this PEP seems to be only solving a fraction of the
> problem.
>
>
>> The file ``pypa.json`` acts as neutron configuration file for pip and other
>> tools that want to build source trees to consult for configuration.
>
> What is a "neutron configuration file"?

Typo - neutral.

> Why is it called "pypa.json" and not the more descriptive
> "pybuild.json" (or, if you prefer, "pip.json")?
> "pypa", as far as I know, is the name of an informal group, not a
> well-known utility, operation or command.

I don't care about the name. As I don't want to be the arbiter of a
bikeshedding thing, the BDFL delegate can choose: until they do, I'm
going to stay with the current name to avoid edit churn.

>> bootstrap_requires
>> Optional list of dependency specifications [#dependencyspec] that must be
>> installed before running the build tool.
>
> How are the requirements gathered and installed? Using setuptools?

By whatever tool is consuming the build system. E.g. pip, or perhaps
conda. Or some new tool. How they do the install is not an
interoperability issue, and thus out of scope for the PEP.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 05:51, Antoine Pitrou  wrote:
> On Wed, 18 Nov 2015 05:40:33 +1300
> Robert Collins  wrote:
>>
>> Its included in the complete grammar, otherwise it can't be tested.
>> Note that that the PEP body refers to the IETF document for the
>> definition of URIs. e.g. exactly what you suggest.
>
> What I suggest is that the grammar doesn't try to define URIs at all,

We don't. We consume the definition the IETF give.

> and instead includes a simple rule that is a superset of URI matching.
> It doesn't make sense for Python packaging tools to detect what is a
> valid URI or not. It's not their job, and the work will probably be
> replicated by whatever URI-loading library they use anyway (since they
> will pass it the URI by string, not by individual components).
>
> The only place where URIs are used seem to be the "urlspec" rule, and
> probably you can accept any opaque string there.

Uhm, why are you making this suggestion? What problem will we solve by
using a proxy rule?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Antoine Pitrou]

On Wed, 18 Nov 2015 05:40:33 +1300
Robert Collins  wrote:
> 
> Its included in the complete grammar, otherwise it can't be tested.
> Note that that the PEP body refers to the IETF document for the
> definition of URIs. e.g. exactly what you suggest.

What I suggest is that the grammar doesn't try to define URIs at all,
and instead includes a simple rule that is a superset of URI matching.
It doesn't make sense for Python packaging tools to detect what is a
valid URI or not. It's not their job, and the work will probably be
replicated by whatever URI-loading library they use anyway (since they
will pass it the URI by string, not by individual components).

The only place where URIs are used seem to be the "urlspec" rule, and
probably you can accept any opaque string there.

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 18 November 2015 at 02:59, Antoine Pitrou  wrote:
> On Tue, 17 Nov 2015 09:46:21 +1300
> Robert Collins  wrote:
>>
>> URI_reference = 
>> URI   = scheme ':' hier_part ('?' query )? ( '#' fragment)?
>> hier_part = ('//' authority path_abempty) | path_absolute |
>> path_rootless | path_empty
>> absolute_URI  = scheme ':' hier_part ( '?' query )?
>> relative_ref  = relative_part ( '?' query )? ( '#' fragment )?
>> relative_part = '//' authority path_abempty | path_absolute |
>> path_noscheme | path_empty
>> scheme= letter ( letter | digit | '+' | '-' | '.')*
>> authority = ( userinfo '@' )? host ( ':' port )?
>> userinfo  = ( unreserved | pct_encoded | sub_delims | ':')*
>> host  = IP_literal | IPv4address | reg_name
>> port  = digit*
>> IP_literal= '[' ( IPv6address | IPvFuture) ']'
>> IPvFuture = 'v' hexdig+ '.' ( unreserved | sub_delims | ':')+
>> IPv6address   = (
>>   ( h16 ':'){6} ls32
>>   | '::' ( h16 ':'){5} ls32
>>   | ( h16 )?  '::' ( h16 ':'){4} ls32
>>   | ( ( h16 ':')? h16 )? '::' ( h16 ':'){3} ls32
>>   | ( ( h16 ':'){0,2} h16 )? '::' ( h16 ':'){2} ls32
>>   | ( ( h16 ':'){0,3} h16 )? '::' h16 ':' ls32
>>   | ( ( h16 ':'){0,4} h16 )? '::' ls32
>>   | ( ( h16 ':'){0,5} h16 )? '::' h16
>>   | ( ( h16 ':'){0,6} h16 )? '::' )
>
> It seems weird that the PEP tries to include an entire subgrammar for
> URIs, including even the parsing various kinds of IP addresses.  Why not
> be lenient in their detection and leave actual definition of valid URIs
> to the IETF?
>
> It doesn't seem there is any point to embed/duplicate such knowledge in
> Python packaging tools.

Its included in the complete grammar, otherwise it can't be tested.
Note that that the PEP body refers to the IETF document for the
definition of URIs. e.g. exactly what you suggest.

-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Leonardo Rochael Almeida]

On 17 November 2015 at 13:20, Daniel Holth  wrote:

> LGTM
>
> Q: Why is build_command a list?
> Q: Why isn't the file name venezuelanbeavercheese.json instead of
> pypa.json?
>

Or why not just use a specific key in setup.cfg instead of a pypa.json
file? ISTM that this PEP expects to find in pypa.json some keys that are
supposed to be entered manually by humans, even though json is a format
more easily written by machines than by humans...

Regards,

Leo

On Tue, Nov 17, 2015 at 10:06 AM Antoine Pitrou  wrote:
>
>> On Tue, 17 Nov 2015 09:33:56 -0500
>> Donald Stufft  wrote:
>> >
>> > > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou 
>> wrote:
>> > >
>> > >>
>> > >> There are a number of separate subcommands that build systems must
>> support.
>> > >
>> > > I wonder how desirable and viable this all is. Desirable, because you
>> > > are still asking the build system to appear as setuptools *in some
>> way*.
>> > > Viable, because pip may some day need to ask more from setuptools and
>> > > then third-party build tools will have to adapt and implement said
>> > > command-line options, defeating the "abstraction".
>> > >
>> > > In other words, this PEP seems to be only solving a fraction of the
>> > > problem.
>> >
>> > Can you explain this? I don’t see how it’s true. We need some way for
>> pip
>> > to invoke the build system no matter what the build system is. Either
>> that
>> > API is a Python API or that build system is a CLI based API but either
>> way
>> > there needs to be some way for that to happen. This PEP chooses (at my
>> > request) a defined CLI API because it makes the delineation between
>> build
>> > system and pip cleaner.
>>
>> I may have misunderstood, it seemed to me that "wheel -d" and "develop"
>> are simply setuptools commands christened by the PEP.
>>
>> I tend to think Python APIs are better than CLI APIs, but that probably
>> doesn't make a lot of difference.  This assumes of course that
>> potential problems are taken care of (such end-of-line conventions and
>> character encodings on stdin / stdout :-)).  The one of thing where a
>> CLI API is clearly inferior is error report, though...
>>
>> > The whole point of this PEP is that once we have it, we can’t just
>> randomly
>> > require more from the build tool than what is in the interface defined
>> in
>> > this PEP. If we need more than we have to write a new PEP that extends
>> the
>> > old interface with a new feature, but at all times it is built on an
>> > interface that is standardized via a PEP.
>>
>> That clears things up, thank you.
>>
>> Regards
>>
>> Antoine.
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] New PyPUG Tutorials

[Marcus Smith]

yea, I was thinking the same.
but we'll see how the initial reorg goes.

On Sun, Nov 15, 2015 at 9:32 PM, Nick Coghlan  wrote:

> On 16 November 2015 at 03:49, Marcus Smith  wrote:
> >>
> >> To have the most success, the writers will certainly need feedback from
> >> subject matter experts, so the process will include 2 stages where we
> >> specifically ask for feedback from PyPA-Dev and Distutils-Sig:  1) To
> >> validate the initial proposal that covers the scope of the changes, and
> 2)
> >> to review the actual PRs to PyPUG for accuracy, when it's time for
> merging.
> >> I'll post again with more details as those stages occur.
> >
> > So, I'm back to post the initial proposal as mentioned above.
>
> That generally looks good to me, but I think we're going to need to
> keep the "Advanced topics" section in one form or another. Longer
> term, it might be possible to split them out into themed subsections
> (as the outline does for pip/easy_install and wheel/egg by moving them
> into the history section), but I don't think reorganising them is at
> all urgent, so that can be tackled after this initial rearrangement is
> done.
>
> 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] build system abstraction PEP, take #2

[Daniel Holth]

LGTM

Q: Why is build_command a list?
Q: Why isn't the file name venezuelanbeavercheese.json instead of pypa.json?

On Tue, Nov 17, 2015 at 10:06 AM Antoine Pitrou  wrote:

> On Tue, 17 Nov 2015 09:33:56 -0500
> Donald Stufft  wrote:
> >
> > > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou 
> wrote:
> > >
> > >>
> > >> There are a number of separate subcommands that build systems must
> support.
> > >
> > > I wonder how desirable and viable this all is. Desirable, because you
> > > are still asking the build system to appear as setuptools *in some
> way*.
> > > Viable, because pip may some day need to ask more from setuptools and
> > > then third-party build tools will have to adapt and implement said
> > > command-line options, defeating the "abstraction".
> > >
> > > In other words, this PEP seems to be only solving a fraction of the
> > > problem.
> >
> > Can you explain this? I don’t see how it’s true. We need some way for pip
> > to invoke the build system no matter what the build system is. Either
> that
> > API is a Python API or that build system is a CLI based API but either
> way
> > there needs to be some way for that to happen. This PEP chooses (at my
> > request) a defined CLI API because it makes the delineation between build
> > system and pip cleaner.
>
> I may have misunderstood, it seemed to me that "wheel -d" and "develop"
> are simply setuptools commands christened by the PEP.
>
> I tend to think Python APIs are better than CLI APIs, but that probably
> doesn't make a lot of difference.  This assumes of course that
> potential problems are taken care of (such end-of-line conventions and
> character encodings on stdin / stdout :-)).  The one of thing where a
> CLI API is clearly inferior is error report, though...
>
> > The whole point of this PEP is that once we have it, we can’t just
> randomly
> > require more from the build tool than what is in the interface defined in
> > this PEP. If we need more than we have to write a new PEP that extends
> the
> > old interface with a new feature, but at all times it is built on an
> > interface that is standardized via a PEP.
>
> That clears things up, thank you.
>
> Regards
>
> Antoine.
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Antoine Pitrou]

On Tue, 17 Nov 2015 09:33:56 -0500
Donald Stufft  wrote:
> 
> > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou  wrote:
> > 
> >> 
> >> There are a number of separate subcommands that build systems must support.
> > 
> > I wonder how desirable and viable this all is. Desirable, because you
> > are still asking the build system to appear as setuptools *in some way*.
> > Viable, because pip may some day need to ask more from setuptools and
> > then third-party build tools will have to adapt and implement said
> > command-line options, defeating the "abstraction".
> > 
> > In other words, this PEP seems to be only solving a fraction of the
> > problem.
> 
> Can you explain this? I don’t see how it’s true. We need some way for pip
> to invoke the build system no matter what the build system is. Either that
> API is a Python API or that build system is a CLI based API but either way
> there needs to be some way for that to happen. This PEP chooses (at my
> request) a defined CLI API because it makes the delineation between build
> system and pip cleaner.

I may have misunderstood, it seemed to me that "wheel -d" and "develop"
are simply setuptools commands christened by the PEP.

I tend to think Python APIs are better than CLI APIs, but that probably
doesn't make a lot of difference.  This assumes of course that
potential problems are taken care of (such end-of-line conventions and
character encodings on stdin / stdout :-)).  The one of thing where a
CLI API is clearly inferior is error report, though...

> The whole point of this PEP is that once we have it, we can’t just randomly
> require more from the build tool than what is in the interface defined in
> this PEP. If we need more than we have to write a new PEP that extends the
> old interface with a new feature, but at all times it is built on an
> interface that is standardized via a PEP.

That clears things up, thank you.

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Donald Stufft]

> On Nov 17, 2015, at 9:27 AM, Antoine Pitrou  wrote:
> 
>> 
>> There are a number of separate subcommands that build systems must support.
> 
> I wonder how desirable and viable this all is. Desirable, because you
> are still asking the build system to appear as setuptools *in some way*.
> Viable, because pip may some day need to ask more from setuptools and
> then third-party build tools will have to adapt and implement said
> command-line options, defeating the "abstraction".
> 
> In other words, this PEP seems to be only solving a fraction of the
> problem.

Can you explain this? I don’t see how it’s true. We need some way for pip
to invoke the build system no matter what the build system is. Either that
API is a Python API or that build system is a CLI based API but either way
there needs to be some way for that to happen. This PEP chooses (at my
request) a defined CLI API because it makes the delineation between build
system and pip cleaner.

The whole point of this PEP is that once we have it, we can’t just randomly
require more from the build tool than what is in the interface defined in
this PEP. If we need more than we have to write a new PEP that extends the
old interface with a new feature, but at all times it is built on an
interface that is standardized via a PEP.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Antoine Pitrou]

On Tue, 17 Nov 2015 15:24:04 +1300
Robert Collins  wrote:
> 
> The programmatic interface allows decoupling of pip from its current
> hard dependency on setuptools [#setuptools]_ able for two
> key reasons:
> 
> 1. It enables new build systems that may be much easier to use without
>requiring them to even appear to be setuptools.

And yet:

> There are a number of separate subcommands that build systems must support.

I wonder how desirable and viable this all is. Desirable, because you
are still asking the build system to appear as setuptools *in some way*.
Viable, because pip may some day need to ask more from setuptools and
then third-party build tools will have to adapt and implement said
command-line options, defeating the "abstraction".

In other words, this PEP seems to be only solving a fraction of the
problem.


> The file ``pypa.json`` acts as neutron configuration file for pip and other
> tools that want to build source trees to consult for configuration.

What is a "neutron configuration file"?

Why is it called "pypa.json" and not the more descriptive
"pybuild.json" (or, if you prefer, "pip.json")?
"pypa", as far as I know, is the name of an informal group, not a
well-known utility, operation or command.

> bootstrap_requires
> Optional list of dependency specifications [#dependencyspec] that must be
> installed before running the build tool.

How are the requirements gathered and installed? Using setuptools?

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Donald Stufft]

> On Nov 17, 2015, at 9:04 AM, Antoine Pitrou  wrote:
> 
> On Tue, 17 Nov 2015 03:33:09 -0800
> Nathaniel Smith  wrote:
>> 
>> Presumably there will be a dependency parser added to the 'packaging'
>> library, which already exists as a standard place to stick stuff like this,
>> so you'll just use that. (E.g. it's what pip uses for PEP 440 version
>> parsing today.)
>> 
>> https://pypi.python.org/pypi/packaging
> 
> Ah... Is this a different thing than distlib? Does one depend on the
> other?
> 
> (this may come to mind: https://www.jwz.org/doc/cadt.html :-))
> 

It’s different yes. distlib took a direction that I wasn’t happy with,
it added a lot of experimental APIs that were not backed by PEPs. I
didn’t think that was appropriate for a reference implementation so I
created that library which will only contain items backed by PEPs (and
any additional items to make it possible to use that PEP in reality,
like LegacyVersion).

All of the new PEP features that pip uses are typically implemented by
packaging and then pip uses it. We also use distlib for a few things,
but I plan to remove that dependency once we have everything we need in
packaging.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Link to lib missing in PEP: FINAL DRAFT: Dependency specifier PEP

[Thomas Güttler]

Am 17.11.2015 um 14:57 schrieb Nick Coghlan:

On 17 November 2015 at 23:43, Thomas Güttler
 wrote:



Am 17.11.2015 um 13:48 schrieb Donald Stufft:




On Nov 17, 2015, at 6:33 AM, Nathaniel Smith mailto:n...@pobox.com>> wrote:

On Nov 16, 2015 11:57 PM, "Thomas Güttler" mailto:guettl...@thomas-guettler.de>> wrote:



The job of a dependency is to enable tools like pip [#pip]_ to find
the right
package to install.


My worries: AFAIK pip is not a library.

I don't want to re-implement code to handle this pep.

I would like to re-use.

But AFAIK pip is not a library.

I am stupid and don't know how to proceed.

Please tell me what to do.


Presumably there will be a dependency parser added to the 'packaging'
library, which already exists as a standard
place to stick stuff like this, so you'll just use that. (E.g. it's what
pip uses for PEP 440 version parsing today.)

https://pypi.python.org/pypi/packaging


Nice, a re-usable library :-)

Since I don't see a reason for two implementations, I think the PEP should
provide a link to the implementation.


No, it shouldn't, as the whole point of these PEPs is to get away from
implementation defined behaviours. If somebody can't implement their
own library from scratch using just the material in the PEP, then the
PEP is incomplete.


I think you are flying to high.

Have you understood what I want?

I just want to add **one** sentence to the PEP:

"This PEP is implemented in "


You always have "implementation defined behaviours" since
the PEP is not executable.

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Antoine Pitrou]

On Tue, 17 Nov 2015 03:33:09 -0800
Nathaniel Smith  wrote:
> 
> Presumably there will be a dependency parser added to the 'packaging'
> library, which already exists as a standard place to stick stuff like this,
> so you'll just use that. (E.g. it's what pip uses for PEP 440 version
> parsing today.)
> 
> https://pypi.python.org/pypi/packaging

Ah... Is this a different thing than distlib? Does one depend on the
other?

(this may come to mind: https://www.jwz.org/doc/cadt.html :-))

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

[Antoine Pitrou]

On Tue, 17 Nov 2015 09:46:21 +1300
Robert Collins  wrote:
> 
> URI_reference = 
> URI   = scheme ':' hier_part ('?' query )? ( '#' fragment)?
> hier_part = ('//' authority path_abempty) | path_absolute |
> path_rootless | path_empty
> absolute_URI  = scheme ':' hier_part ( '?' query )?
> relative_ref  = relative_part ( '?' query )? ( '#' fragment )?
> relative_part = '//' authority path_abempty | path_absolute |
> path_noscheme | path_empty
> scheme= letter ( letter | digit | '+' | '-' | '.')*
> authority = ( userinfo '@' )? host ( ':' port )?
> userinfo  = ( unreserved | pct_encoded | sub_delims | ':')*
> host  = IP_literal | IPv4address | reg_name
> port  = digit*
> IP_literal= '[' ( IPv6address | IPvFuture) ']'
> IPvFuture = 'v' hexdig+ '.' ( unreserved | sub_delims | ':')+
> IPv6address   = (
>   ( h16 ':'){6} ls32
>   | '::' ( h16 ':'){5} ls32
>   | ( h16 )?  '::' ( h16 ':'){4} ls32
>   | ( ( h16 ':')? h16 )? '::' ( h16 ':'){3} ls32
>   | ( ( h16 ':'){0,2} h16 )? '::' ( h16 ':'){2} ls32
>   | ( ( h16 ':'){0,3} h16 )? '::' h16 ':' ls32
>   | ( ( h16 ':'){0,4} h16 )? '::' ls32
>   | ( ( h16 ':'){0,5} h16 )? '::' h16
>   | ( ( h16 ':'){0,6} h16 )? '::' )

It seems weird that the PEP tries to include an entire subgrammar for
URIs, including even the parsing various kinds of IP addresses.  Why not
be lenient in their detection and leave actual definition of valid URIs
to the IETF?

It doesn't seem there is any point to embed/duplicate such knowledge in
Python packaging tools.

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Link to lib missing in PEP: FINAL DRAFT: Dependency specifier PEP

[Nick Coghlan]

On 17 November 2015 at 23:43, Thomas Güttler
 wrote:
>
>
> Am 17.11.2015 um 13:48 schrieb Donald Stufft:
>>
>>
>>> On Nov 17, 2015, at 6:33 AM, Nathaniel Smith >> > wrote:
>>>
>>> On Nov 16, 2015 11:57 PM, "Thomas Güttler" >> > wrote:
>>> >
>>> > > The job of a dependency is to enable tools like pip [#pip]_ to find
>>> > > the right
>>> > > package to install.
>>> >
>>> > My worries: AFAIK pip is not a library.
>>> >
>>> > I don't want to re-implement code to handle this pep.
>>> >
>>> > I would like to re-use.
>>> >
>>> > But AFAIK pip is not a library.
>>> >
>>> > I am stupid and don't know how to proceed.
>>> >
>>> > Please tell me what to do.
>>>
>>> Presumably there will be a dependency parser added to the 'packaging'
>>> library, which already exists as a standard
>>> place to stick stuff like this, so you'll just use that. (E.g. it's what
>>> pip uses for PEP 440 version parsing today.)
>>>
>>> https://pypi.python.org/pypi/packaging
>
> Nice, a re-usable library :-)
>
> Since I don't see a reason for two implementations, I think the PEP should
> provide a link to the implementation.

No, it shouldn't, as the whole point of these PEPs is to get away from
implementation defined behaviours. If somebody can't implement their
own library from scratch using just the material in the PEP, then the
PEP is incomplete.

However, it may be worth pointing to "packaging" from
https://packaging.python.org/en/latest/current/ for the sake of folks
implementing their own tooling (or adapting existing tools). At the
moment, I believe the only reference is from the full project listing
at https://packaging.python.org/en/latest/projects/#packaging

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] Link to lib missing in PEP: FINAL DRAFT: Dependency specifier PEP

[Thomas Güttler]

Am 17.11.2015 um 13:48 schrieb Donald Stufft:



On Nov 17, 2015, at 6:33 AM, Nathaniel Smith mailto:n...@pobox.com>> wrote:

On Nov 16, 2015 11:57 PM, "Thomas Güttler" mailto:guettl...@thomas-guettler.de>> wrote:
>
> > The job of a dependency is to enable tools like pip [#pip]_ to find the 
right
> > package to install.
>
> My worries: AFAIK pip is not a library.
>
> I don't want to re-implement code to handle this pep.
>
> I would like to re-use.
>
> But AFAIK pip is not a library.
>
> I am stupid and don't know how to proceed.
>
> Please tell me what to do.

Presumably there will be a dependency parser added to the 'packaging' library, 
which already exists as a standard
place to stick stuff like this, so you'll just use that. (E.g. it's what pip 
uses for PEP 440 version parsing today.)

https://pypi.python.org/pypi/packaging


Nice, a re-usable library :-)

Since I don't see a reason for two implementations, I think the PEP should
provide a link to the implementation.

Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Donald Stufft]

> On Nov 17, 2015, at 6:33 AM, Nathaniel Smith  wrote:
> 
> On Nov 16, 2015 11:57 PM, "Thomas Güttler"  > wrote:
> >
> > > The job of a dependency is to enable tools like pip [#pip]_ to find the 
> > > right
> > > package to install.
> >
> > My worries: AFAIK pip is not a library.
> >
> > I don't want to re-implement code to handle this pep.
> >
> > I would like to re-use.
> >
> > But AFAIK pip is not a library.
> >
> > I am stupid and don't know how to proceed.
> >
> > Please tell me what to do.
> 
> Presumably there will be a dependency parser added to the 'packaging' 
> library, which already exists as a standard place to stick stuff like this, 
> so you'll just use that. (E.g. it's what pip uses for PEP 440 version parsing 
> today.)
> 
> https://pypi.python.org/pypi/packaging 
> 
> 

https://github.com/pypa/packaging/pull/45 


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Nathaniel Smith]

On Nov 16, 2015 11:57 PM, "Thomas Güttler" 
wrote:
>
> > The job of a dependency is to enable tools like pip [#pip]_ to find the
right
> > package to install.
>
> My worries: AFAIK pip is not a library.
>
> I don't want to re-implement code to handle this pep.
>
> I would like to re-use.
>
> But AFAIK pip is not a library.
>
> I am stupid and don't know how to proceed.
>
> Please tell me what to do.

Presumably there will be a dependency parser added to the 'packaging'
library, which already exists as a standard place to stick stuff like this,
so you'll just use that. (E.g. it's what pip uses for PEP 440 version
parsing today.)

https://pypi.python.org/pypi/packaging

-n
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Thomas Güttler]

Am 17.11.2015 um 09:02 schrieb Robert Collins:

On 17 November 2015 at 20:57, Thomas Güttler
 wrote:

The job of a dependency is to enable tools like pip [#pip]_ to find the right
package to install.


My worries: AFAIK pip is not a library.

I don't want to re-implement code to handle this pep.

I would like to re-use.

But AFAIK pip is not a library.

I am stupid and don't know how to proceed.

Please tell me what to do.


What are you trying to accomplish?


I want to parse a single dependency of a python
package.



--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

[Robert Collins]

On 17 November 2015 at 20:57, Thomas Güttler
 wrote:
>> The job of a dependency is to enable tools like pip [#pip]_ to find the right
>> package to install.
>
> My worries: AFAIK pip is not a library.
>
> I don't want to re-implement code to handle this pep.
>
> I would like to re-use.
>
> But AFAIK pip is not a library.
>
> I am stupid and don't know how to proceed.
>
> Please tell me what to do.

What are you trying to accomplish?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP, take #2

[Ronny Pfannschmidt]

I forgot to reply to the list, so I re-added it

To further explain, in my setuptools replacement experiment I implement the 
develop command by generating a a wheel
Using a local version tag `+develop`,

Instead of the actual code, for each top-level it contains a shim python file 
that will load the real code from the editable location
However it will use pip to install that wheel and create scripts/exe files

In particular windows support for a full develop command is orders of magnitude 
more easy if one let's pip make the scripts(exe files)

I think it's very helpful for tool authors if pip has ways for them to avoid 
platform pitfalls like exe files 


Am 17. November 2015 08:15:41 MEZ, schrieb Robert Collins 
:
>On 17 November 2015 at 19:16, Ronny Pfannschmidt
> wrote:
>> The develop command should be able to generate a wheel with a local
>version
>> that pip can install
>> That way tool authors can completely avoid writing the target folders
>and
>> its possible to always run completely unprivileged builds
>
>Thats an interesting idea, but wholly different to what 'develop' does
>and is used for. My goal here is to only commit to new things where
>the new thing is all of:
> - a small amount of work
> - meets existing use cases
> - able to be put into pip/setuptools/wheel/etc now (rather than after
>a bunch of other things are done)
>
>I completely agree with the idea that develop as it stands has a
>number of limitations, but there is no generic implementation
>available for pip to reuse; there is no feature in pip that would do
>what you want either; nor even a proof of concept. I think as such its
>premature to PEPify it.
>
>What could be done is to take the abstract build system work (which
>*is* within reach for pip) and create a implementation with a new
>schema version and whatever semantics you want around this new
>developish thing, and write an incremental PEP (so you don't need any
>of the PEP I've put up, just inherit from it and define your new thing
>- and then we can kick the tires on it and see how its going to work
>etc.
>
>Note that what you describe 'generate a wheel with a local version' is
>actually exactly what the 'wheel' command does as far as I can tell,
>but I'm sure thats not what you have in mind - so please do expand on
>the differences, in
>paranoid-folk-make-sure-folk-cannot-misunderstand-style ;)
>
>-Rob
>
>
>-- 
>Robert Collins 
>Distinguished Technologist
>HP Converged Cloud

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig