Re: [Distutils] setuptools tracker

[PJ Eby]

I think it would be a good idea to check with Jason and other PyPA
volunteers to see if there is anyone else who can handle the moves.  I'd
prefer we didn't lose the history, since my comments on those issues (and
the closed ones, too) often contain key information about use cases and
design decisions that may not be available elsewhere, even from my memory.
;-)  But, since I'm no longer in the lead on development, I think it would
be better for someone closer to the future of things to do the prioritizing
of what, if anything, to transfer as an issue or keep as documentation.


On Sun, Mar 23, 2014 at 2:00 PM, "Martin v. Löwis" wrote:

> Am 23.03.14 18:30, schrieb PJ Eby:
> > On Sun, Mar 23, 2014 at 4:55 AM, "Martin v. Löwis"  > > wrote:
> >
> > We are still hosting a roundup installation for setuptools,
> > at http://bugs.python.org/setuptools/.
> >
> > Is this still needed? If not: what should we do with it?
> >
> >
> > I think probably the remaining issues need to be moved to Bitbucket
> > (unless they're already addressed in later setuptools versions), and the
> > tracker closed.  At this point, I think it's safe to say that the 0.6
> > line isn't getting any more changes; persons and organizations using
> > older versions of Python will have to take 0.6 as it is, or upgrade.
>
> Would you volunteer to move them? Alternatively, I could close them all
> with an automatic message saying that they should re-report them if the
> issue still exists.
>
> Regards,
> Martin
>
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Paul Moore]

On 23 March 2014 23:13, Nick Coghlan  wrote:
> Now you begin to see the scope of the problem. It's definitely solvable, but
> means asking a whole pile of "required, recommended or distutils-specific?"
> questions about the existing distutils and setuptools build system :)
>
> "pip already relies on it" sets the minimum for the "required" category, but
> there's more to a full build system abstraction than what pip currently
> supports.

OK, I see now. So the ultimate build system will include pip changes
to supply build-time options in an as-yet unspecified manner.

There's certainly no way I can do all of that myself, I don't have
remotely the level of experience with complex build requirements. But
I can probably take the first steps, and leave it to people with the
experience to add to it. No promises on timescales but I'll see what I
can do.

One thought. do we want to use a setup.py script as the interface,
with all its historical baggage, or would we be better using a new
script name as the "official" interface (with pip falling back to
equivalent setup.py invocations when that script isn't present, for
backward compatibility)?

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

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

[Nick Coghlan]

On 24 Mar 2014 00:13, "Paul Moore"  wrote:
>
> On 23 March 2014 00:00, Nick Coghlan  wrote:
> > On 23 Mar 2014 09:35, "Paul Moore"  wrote:
> >>
> >> On 22 March 2014 22:37, Vinay Sajip  wrote:
> >> >> 1. Formally decouple the setup.py CLI from the distutils command
system
> >> >
> >> > Agreed - it looks like a compatible CLI needs to be part of the
> >> > transition
> >> > to any new system (I assume that's what you meant).
> >>
> >> Does this statement mean "document the exact setup.py invocations
> >> which need to be supported by any tool" or does it mean "create a new
> >> standard cli and update pip to use it and sort out a means of wrapping
> >> existing setup.py scripts to expose it"? If the former, then I've
> >> informally done that earlier in the thread (basically "setup.py
> >> bdist_wheel -d XXX" is it[1], if we assume that by the time it's
> >> official pip will have completed the move to installing from sdist by
> >> using wheels as an intermediate step). Writing a wrapper setup.py that
> >> simply invokes a different tool such as bento is trivial.
> >
> > I mean actually writing it up and documenting all the *build options*
> > (including cross compilation support). As far as I am aware, that hasn't
> > been done to date (at least, not in an easily consumable form that
people
> > can link to).
>
> Hmm. How about if, to start the ball rolling, I add a short section to
> the pip documentation entitled "setup.py interface" that explains the
> basic commands that pip uses. That can then be expanded on as
> additional data is collected.

Yes, explaining the interface that pip currently relies on would definitely
be a good starting point.

> One thing though. I may be being dense here, but I'm not aware of any
> way for pip to provide build options via "pip wheel". I certainly
> don't know the pip wheel command you'd use to (for example)
> cross-compile psutil for Windows on a Linux box. Or how you'd use pip
> wheel to build pyYAML with libyaml support (you need to indicate where
> the libyaml headers and library live). Obviously you can do this with
> *distutils*, but that's different. We're not expecting bento, or
> distil, or waf, or whatever, to support the full distutils command
> line interface, surely?

Now you begin to see the scope of the problem. It's definitely solvable,
but means asking a whole pile of "required, recommended or
distutils-specific?" questions about the existing distutils and setuptools
build system :)

"pip already relies on it" sets the minimum for the "required" category,
but there's more to a full build system abstraction than what pip currently
supports.

Cheers,
Nick.

>
> The pip wheel command includes --build-options and --build-options
> flags that translate to global and command-specific options on the
> bdist_wheel command. Those are as follows:
>
> Global options:
>   --verbose (-v)  run verbosely (default)
>   --quiet (-q)run quietly (turns verbosity off)
>   --dry-run (-n)  don't actually do anything
>   --help (-h) show detailed help message
>   --no-user-cfg   ignore pydistutils.cfg in your home directory
>
> Options for 'bdist_wheel' command:
>   --bdist-dir (-b)  temporary directory for creating the distribution
>   --plat-name (-p)  platform name to embed in generated filenames
(default:
> win-amd64)
>   --keep-temp (-k)  keep the pseudo-installation tree around after
creating
> the distribution archive
>   --dist-dir (-d)   directory to put final built distributions in
>   --skip-build  skip rebuilding everything (for testing/debugging)
>   --relativebuild the archive using relative paths(default: false)
>   --owner (-u)  Owner name used when creating a tar file [default:
current
> user]
>   --group (-g)  Group name used when creating a tar file [default:
current
> group]
>   --skip-scriptsskip building the setuptools console_scripts
>   --universal   make a universal wheel (default: false)
>
> Note that none of those control the build - the ones that do that are
> options to the build_ext and build commands, but *distutils* doesn't
> allow you to supply them in a bdist_wheel command. The same is true
> for pip install, BTW. That sends the options to the setup.py install
> command - again, not to setup.py build_ext.
>
> I can imagine good ways of using the existing pip interface to drive
> build tools (even distutils!) more effectively than we do at present.
> But I don't think the current interface supports compilation arguments
> (even if it looks like it does).
>
> Paul.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setuptools tracker

[Martin v. Löwis]

Am 23.03.14 18:30, schrieb PJ Eby:
> On Sun, Mar 23, 2014 at 4:55 AM, "Martin v. Löwis"  > wrote:
> 
> We are still hosting a roundup installation for setuptools,
> at http://bugs.python.org/setuptools/.
> 
> Is this still needed? If not: what should we do with it?
> 
> 
> I think probably the remaining issues need to be moved to Bitbucket
> (unless they're already addressed in later setuptools versions), and the
> tracker closed.  At this point, I think it's safe to say that the 0.6
> line isn't getting any more changes; persons and organizations using
> older versions of Python will have to take 0.6 as it is, or upgrade.

Would you volunteer to move them? Alternatively, I could close them all
with an automatic message saying that they should re-report them if the
issue still exists.

Regards,
Martin


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

Re: [Distutils] setuptools tracker

[PJ Eby]

On Sun, Mar 23, 2014 at 4:55 AM, "Martin v. Löwis" wrote:

> We are still hosting a roundup installation for setuptools,
> at http://bugs.python.org/setuptools/.
>
> Is this still needed? If not: what should we do with it?
>
>
I think probably the remaining issues need to be moved to Bitbucket (unless
they're already addressed in later setuptools versions), and the tracker
closed.  At this point, I think it's safe to say that the 0.6 line isn't
getting any more changes; persons and organizations using older versions of
Python will have to take 0.6 as it is, or upgrade.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Paul Moore]

On 23 March 2014 00:00, Nick Coghlan  wrote:
> On 23 Mar 2014 09:35, "Paul Moore"  wrote:
>>
>> On 22 March 2014 22:37, Vinay Sajip  wrote:
>> >> 1. Formally decouple the setup.py CLI from the distutils command system
>> >
>> > Agreed - it looks like a compatible CLI needs to be part of the
>> > transition
>> > to any new system (I assume that's what you meant).
>>
>> Does this statement mean "document the exact setup.py invocations
>> which need to be supported by any tool" or does it mean "create a new
>> standard cli and update pip to use it and sort out a means of wrapping
>> existing setup.py scripts to expose it"? If the former, then I've
>> informally done that earlier in the thread (basically "setup.py
>> bdist_wheel -d XXX" is it[1], if we assume that by the time it's
>> official pip will have completed the move to installing from sdist by
>> using wheels as an intermediate step). Writing a wrapper setup.py that
>> simply invokes a different tool such as bento is trivial.
>
> I mean actually writing it up and documenting all the *build options*
> (including cross compilation support). As far as I am aware, that hasn't
> been done to date (at least, not in an easily consumable form that people
> can link to).

Hmm. How about if, to start the ball rolling, I add a short section to
the pip documentation entitled "setup.py interface" that explains the
basic commands that pip uses. That can then be expanded on as
additional data is collected.

One thing though. I may be being dense here, but I'm not aware of any
way for pip to provide build options via "pip wheel". I certainly
don't know the pip wheel command you'd use to (for example)
cross-compile psutil for Windows on a Linux box. Or how you'd use pip
wheel to build pyYAML with libyaml support (you need to indicate where
the libyaml headers and library live). Obviously you can do this with
*distutils*, but that's different. We're not expecting bento, or
distil, or waf, or whatever, to support the full distutils command
line interface, surely?

The pip wheel command includes --build-options and --build-options
flags that translate to global and command-specific options on the
bdist_wheel command. Those are as follows:

Global options:
  --verbose (-v)  run verbosely (default)
  --quiet (-q)run quietly (turns verbosity off)
  --dry-run (-n)  don't actually do anything
  --help (-h) show detailed help message
  --no-user-cfg   ignore pydistutils.cfg in your home directory

Options for 'bdist_wheel' command:
  --bdist-dir (-b)  temporary directory for creating the distribution
  --plat-name (-p)  platform name to embed in generated filenames (default:
win-amd64)
  --keep-temp (-k)  keep the pseudo-installation tree around after creating
the distribution archive
  --dist-dir (-d)   directory to put final built distributions in
  --skip-build  skip rebuilding everything (for testing/debugging)
  --relativebuild the archive using relative paths(default: false)
  --owner (-u)  Owner name used when creating a tar file [default: current
user]
  --group (-g)  Group name used when creating a tar file [default: current
group]
  --skip-scriptsskip building the setuptools console_scripts
  --universal   make a universal wheel (default: false)

Note that none of those control the build - the ones that do that are
options to the build_ext and build commands, but *distutils* doesn't
allow you to supply them in a bdist_wheel command. The same is true
for pip install, BTW. That sends the options to the setup.py install
command - again, not to setup.py build_ext.

I can imagine good ways of using the existing pip interface to drive
build tools (even distutils!) more effectively than we do at present.
But I don't think the current interface supports compilation arguments
(even if it looks like it does).

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

[Distutils] setuptools tracker

[Martin v. Löwis]

We are still hosting a roundup installation for setuptools,
at http://bugs.python.org/setuptools/.

Is this still needed? If not: what should we do with it?

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