Re: [Distutils] draft PEP: manylinux1

[Robert McGibbon]

Another wrinkle: it also should be possible, I think, for wheels to include
binaries that are linked against shared libraries that are provided by other
wheels (that are part of the  install_requires), but I haven't thought much
about this. I know Nathaniel has been thinking about this type of thing for
a separate BLAS wheel package that, for example, numpy could depend
on.

I assume that this type of thing should be kosher within the manylinux1
policy, although the text of the draft PEP does not definitely address it.

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

Re: [Distutils] draft PEP: manylinux1

[Robert McGibbon]

On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan  wrote:

>
> I think it's better to start with a small core that we *know* works,
> then expand later, rather than trying to make the first iteration too
> wide. The "manylinux1" tag itself is versioned (hence the "1" at the
> end), so "manylinux2" may simply have *more* libraries defined, rather
> than newer ones.
>
> The key is that we only have one chance to make a good first
> impression with binary Linux wheel support on PyPI, and we want that
> to be positive for everyone:
>
> * for publishers, going from "no Linux wheels" to "Linux wheels if you
> have few external dependencies beyond glibc" is a big step up (it's
> enough for a Cython accelerator module, for example, or a cffi wrapper
> around a bundled library)
> * for end users, we need to nigh certain that wheels built this way
> will *just work*
>


In general, I see a tension between permissiveness and flexibility in the
policy
here, with good arguments on both sides. A restrictive policy (like the one
we
propose) will keep some wheels off PyPI that would work just fine on most
Linux boxes. But it will also ensure that fewer broken packages are
uploaded.

In my opinion, the packaging system we have currently works pretty well.
Adopting a loose policy could therefore be experienced as a regression for
users who type ``pip install ` and receive a broken binary wheel.
This is one of the reasons we thought that it would be safest to start small
and work incrementally.

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

Re: [Distutils] draft PEP: manylinux1

[Robert McGibbon]

After I posted the PEP link on social media, a friend of mine, Kyle
Beauchamp, asked: "I wonder if there are speed and correctness implications
to always reverting to the lowest common denominator of glibc."

For speed, I believe there is some consequence, in that the maximum gcc
version you can realistically use with glibc <= 2.5 is gcc 4.8.2, which is
presumably somewhat (although not much) slower than the latest gcc release.
As to correctness, it seems like a reasonable concern, and I don't know one
way or the other. I thought maybe someone on the list would know.

There are also potential compatibility issues in wheels that use certain
instruction set extensions (SSE 4, AVX, etc) that might not be available on
certain platforms. I think policies on this issue are better left up to
individual packages than set at a PEP-wide level, but it also may be worth
talking about.

-Robert


On Thu, Jan 21, 2016 at 1:03 AM, M.-A. Lemburg  wrote:

>
> Robert McGibbon: Thanks for writing up this PEP :-)
>
> Some comments below...
>
> On 21.01.2016 04:55, Nathaniel Smith wrote:
> > The ``manylinux1`` policy
> > =
> >
> > For these reasons, to achieve broad portability, Python wheels
> >
> >  * should depend only on an extremely limited set of external shared
> >libraries; and
> >  * should depend only on ``old`` symbol versions in those external shared
> >libraries.
> >
> > The ``manylinux1`` policy thus encompasses a standard for what the
> > permitted external shared libraries a wheel may depend on, and the
> maximum
> > depended-upon symbol versions therein.
> >
> > The permitted external shared libraries are: ::
> >
> > libpanelw.so.5
> > libncursesw.so.5
> > libgcc_s.so.1
> > libstdc++.so.6
> > libm.so.6
> > libdl.so.2
> > librt.so.1
> > libcrypt.so.1
> > libc.so.6
> > libnsl.so.1
> > libutil.so.1
> > libpthread.so.0
> > libX11.so.6
> > libXext.so.6
> > libXrender.so.1
> > libICE.so.6
> > libSM.so.6
> > libGL.so.1
> > libgobject-2.0.so.0
> > libgthread-2.0.so.0
> > libglib-2.0.so.0
>
> The list is good start, but limiting the possible external
> references to only these libraries will make it impossible
> to have manylinux1 wheels which link against other, similarly
> old, but very common libraries, or alternatively rather
> new ones, which are then optionally included via subpackage
> instead of being mandatory.
>
> At eGenix we have been tackling this problem for years with
> our extensions and the approach that's been the most
> successful was to simply use Linux build systems which
> are at least 5 years old. In our case, that's openSUSE 11.3.
>
> I think a better approach is to use the above list to
> test for used library *versions* and then apply the tag
> based on the findings.
>
> If a package includes binaries which link to e.g.
> later libc.so versions, it would be rejected. If it
> includes other libraries not listed in the above listing,
> that's fine, as long as these libraries also comply to
> the version limitation.
>
> What I'm getting at here is that incompatibilities are
> not caused by libraries being absent on the system
> (the package simply won't load, but that's not due to the
> the package being incompatible to the platform, only due
> to the system lacking a few packages), but instead by
> having the packages use more recent versions of these
> system libraries.
>
> > Compilation and Tooling
> > ===
> >
> > To support the compilation of wheels meeting the ``manylinux1``
> standard, we
> > provide initial drafts of two tools.
> >
> > The first is a Docker image based on CentOS 5.11, which is recommended
> as an
> > easy to use self-contained build box for compiling ``manylinux1`` wheels
> [4]_.
> > Compiling on a more recently-released linux distribution will generally
> > introduce dependencies on too-new versioned symbols. The image comes
> with a
> > full compiler suite installed (``gcc``, ``g++``, and ``gfortran`` 4.8.2)
> as
> > well as the latest releases of Python and pip.
> >
> > The second tool is a command line executable called ``auditwheel`` [5]_.
> First,
> > it inspects all of the ELF files inside a wheel to check for
> dependencies on
> > versioned symbols or external shared libraries, and verifies conformance
> with
> > the ``manylinux1`` policy. This includes the ability to add the new
> platform
> > tag to conforming wheels.

Re: [Distutils] draft PEP: manylinux1

[Robert McGibbon]

Hi Nick,

The text version is here:
https://raw.githubusercontent.com/manylinux/manylinux/master/pep-.rst

-Robert

On Wed, Jan 20, 2016 at 10:17 PM, Nick Coghlan  wrote:

> On 21 January 2016 at 13:55, Nathaniel Smith  wrote:
> > Hi all,
> >
> > Here's a first draft of a PEP for the manylinux1 platform tag
> > mentioned earlier, posted for feedback. Really Robert McGibbon should
> > get the main credit for this, since he wrote it, and also the docker
> > image and the amazing auditwheel tool linked below, but he asked me to
> > do the honors of posting it :-).
>
> Very nice!
>
> Do you have a link to the text file version of that? I can assign it a
> number and add it to the PEPs repo.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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] nightly build just started failing with TypeError: must be type, not classobj on Python 2.7

[Robert McGibbon]

It looks like this is a setuptools bug that has been reported upstream [1].

[1]
https://bitbucket.org/pypa/setuptools/issues/464/typeerror-in-install_wrapper_scripts

-Robert

On Tue, Nov 24, 2015 at 2:37 PM, Chris Withers 
wrote:

> Looks like it's not isolated to that package:
>
> https://travis-ci.org/Simplistix/mush/jobs/93042214
>
> On 24/11/2015 21:25, Chris Withers wrote:
>
> Hi All,
>
> Nightly builds of one of my packages (
> https://travis-ci.org/Mortar/mortar_rdb) just began failing with:
>
> TypeError: must be type, not classobj
>
> ...but only on Python 2. The full traceback is here:
>
> https://travis-ci.org/Mortar/mortar_rdb/jobs/93030519#L256
>
> I haven't pushed any changed to that project in a few weeks/days.
>
> Does anyone know what might have changed to cause this problem? I couldn't
> see any recent releases of setuptools or pip, so wondering what I'm
> missing...
>
> cheers,
>
> Chris
>
>
>
> ___
> 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] Installing packages using pip

[Robert McGibbon]

But I think dll/pyd files from extension modules present more of a
challenge, since they're left open. I recall some issues around this with
conda (e.g. https://github.com/conda/conda-build/pull/520)

-Robert

On Sun, Nov 15, 2015 at 12:31 PM, Paul Moore  wrote:

> On 15 November 2015 at 20:25, Chris Barker - NOAA Federal
>  wrote:
> > Though I suspect that Window's aggressive file locking will put the
> kibosh
> > on in-place upgrades :)
>
> Generally, no. Python loads pyc files with a single read, it doesn't
> leave the files open. The only locking issues are when you try to
> upgrade a wrapper exe while it's in use. That might affect you if you
> try to upgrade IPython from within IPython, but otherwise it's
> probably fine.
>
> Paul
> ___
> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

Hi,

> Trust me on that :-)

That's not really the point -- I use both conda and pip, maintain
https://github.com/omnia-md/conda-recipes, and have made multiple upstream
contributions to conda-build.

The point of this thread, from my perspective, was to confirm that there's
a small bug in pip in the way it determines the supported pep425 tags. I
think I've confirmed that, and I'll file a PR shortly.

-Robert

On Fri, Nov 6, 2015 at 4:04 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> On Nov 6, 2015, at 3:57 PM, Robert McGibbon  wrote:
>
> I'm using the Python from the Miniconda installer with py35 released last
> week.
>
>
> Then you should not expect it to be able to find compatible binary wheels
> on PyPi.
>
> Pretty much the entire point of conda is to support Numpy and friends.
> It's actually really good that it DIDN'T go and install a binary wheel.
>
> You want:
>
> conda install numpy
>
> Trust me on that :-)
>
> There are some cases where pip installing a source package into a conda
> Python is fine -- but mostly only pure-Python packages.
>
> -CHB
>
>
>
> What does the python.org installer build for 10.6+ return for
> `distutils.util.get_platform()`?
>
> -Robert
>
> On Fri, Nov 6, 2015 at 2:50 PM, Ned Deily  wrote:
>
>> In article
>> ,
>>  Robert McGibbon  wrote:
>> > I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it
>> > proceeds to download and compile the tarball from PyPI from source (very
>> > slow). I see, however, that pre-compiled OS X wheel files are available
>> on
>> > PyPI for OS X 10.6 and later.
>> >
>> > Checking the code, it looks like pip is picking up the platform tag
>> through
>> > `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on
>> this
>> > machine. At root, I think this comes from the
>> MACOSX_DEPLOYMENT_TARGET=10.5
>> > entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that
>> this
>> > value is used by distutils compiling python extension modules --
>> presumably
>> > so that they can be distributed to any target machine with OS X >=10.5
>> --
>> > so that's good. But is this the right thing for pip to be using when
>> > checking whether a binary wheel is compatible? I see it mentioned
>> > <https://www.python.org/dev/peps/pep-0425/#id13> in PEP 425, so perhaps
>> > this was already hashed out on the list.
>>
>> Are you using an OS X Python installed from a python.org installer?  If
>> so, be aware that there are two different OS X installers on Python.org
>> <http://python.org>
>> for each current release.  One is intended for 10.5 systems, although it
>> will work on later OS X systems.  The other is for 10.6 and later
>> systems.  Unless you have a need to run on 10.5 or build something that
>> works on 10.5, download and use the 10.6+ installers instead.  Then the
>> existing whls for products like Numpy should work just fine.
>>
>> --
>>  Ned Deily,
>>  n...@acm.org
>>
>> ___
>> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

I'm using the Python from the Miniconda installer with py35 released last
week.

What does the python.org installer build for 10.6+ return for
`distutils.util.get_platform()`?

-Robert

On Fri, Nov 6, 2015 at 2:50 PM, Ned Deily  wrote:

> In article
> ,
>  Robert McGibbon  wrote:
> > I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it
> > proceeds to download and compile the tarball from PyPI from source (very
> > slow). I see, however, that pre-compiled OS X wheel files are available
> on
> > PyPI for OS X 10.6 and later.
> >
> > Checking the code, it looks like pip is picking up the platform tag
> through
> > `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on
> this
> > machine. At root, I think this comes from the
> MACOSX_DEPLOYMENT_TARGET=10.5
> > entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that
> this
> > value is used by distutils compiling python extension modules --
> presumably
> > so that they can be distributed to any target machine with OS X >=10.5 --
> > so that's good. But is this the right thing for pip to be using when
> > checking whether a binary wheel is compatible? I see it mentioned
> > <https://www.python.org/dev/peps/pep-0425/#id13> in PEP 425, so perhaps
> > this was already hashed out on the list.
>
> Are you using an OS X Python installed from a python.org installer?  If
> so, be aware that there are two different OS X installers on Python.org
> for each current release.  One is intended for 10.5 systems, although it
> will work on later OS X systems.  The other is for 10.6 and later
> systems.  Unless you have a need to run on 10.5 or build something that
> works on 10.5, download and use the 10.6+ installers instead.  Then the
> existing whls for products like Numpy should work just fine.
>
> --
>  Ned Deily,
>  n...@acm.org
>
> ___
> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

Sounds good. I'll take a look.

-Robert

On Fri, Nov 6, 2015 at 11:23 AM, Daniel Holth  wrote:

> If you would like to fix the problem, figure out how to get the real OSX
> version into pip.pep425tags.
>
> On Fri, Nov 6, 2015 at 2:20 PM Robert McGibbon  wrote:
>
>> For OS X, the pip get_platform function eventually calls into here:
>> https://github.com/python/cpython/blob/master/Lib/_osx_support.py#L429-L439,
>> and I think the comment kind of explains the bug.
>>
>> -Robert
>>
>>
>>
>> On Fri, Nov 6, 2015 at 11:10 AM, Daniel Holth  wrote:
>>
>>> I see what you mean. Sounds like a bug to me.
>>>
>>> On Fri, Nov 6, 2015 at 2:07 PM Robert McGibbon 
>>> wrote:
>>>
>>>> I don't think it's the sorting, per se. All of the get_supported()
>>>> tags are 10.5 or earlier. Here's the output:
>>>> https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9
>>>>
>>>>
>>>> On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth  wrote:
>>>>
>>>>> It should already be sorted. Try python -c "import pprint,
>>>>> pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"
>>>>>
>>>>> Do none of the tags for the available numpy wheels appear in that list?
>>>>>
>>>>> On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just tried to run `pip install numpy` on my OS X 10.10.3 box, and
>>>>>> it proceeds to download and compile the tarball from PyPI from source 
>>>>>> (very
>>>>>> slow). I see, however, that pre-compiled OS X wheel files are available 
>>>>>> on
>>>>>> PyPI for OS X 10.6 and later.
>>>>>>
>>>>>> Checking the code, it looks like pip is picking up the platform tag
>>>>>> through `distutils.util.get_platform()`, which returns 
>>>>>> 'macosx-10.5-x86_64'
>>>>>> on this machine. At root, I think this comes from
>>>>>> the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at
>>>>>> `python3.5/config-3.5m/Makefile`. I know that this value is used by
>>>>>> distutils compiling python extension modules -- presumably so that they 
>>>>>> can
>>>>>> be distributed to any target machine with OS X >=10.5 -- so that's good.
>>>>>> But is this the right thing for pip to be using when checking whether a
>>>>>> binary wheel is compatible? I see it mentioned
>>>>>> <https://www.python.org/dev/peps/pep-0425/#id13> in PEP 425, so
>>>>>> perhaps this was already hashed out on the list.
>>>>>>
>>>>>> Best,
>>>>>> Robert
>>>>>> ___
>>>>>> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

For OS X, the pip get_platform function eventually calls into here:
https://github.com/python/cpython/blob/master/Lib/_osx_support.py#L429-L439,
and I think the comment kind of explains the bug.

-Robert



On Fri, Nov 6, 2015 at 11:10 AM, Daniel Holth  wrote:

> I see what you mean. Sounds like a bug to me.
>
> On Fri, Nov 6, 2015 at 2:07 PM Robert McGibbon  wrote:
>
>> I don't think it's the sorting, per se. All of the get_supported() tags
>> are 10.5 or earlier. Here's the output:
>> https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9
>>
>>
>> On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth  wrote:
>>
>>> It should already be sorted. Try python -c "import pprint,
>>> pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"
>>>
>>> Do none of the tags for the available numpy wheels appear in that list?
>>>
>>> On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it
>>>> proceeds to download and compile the tarball from PyPI from source (very
>>>> slow). I see, however, that pre-compiled OS X wheel files are available on
>>>> PyPI for OS X 10.6 and later.
>>>>
>>>> Checking the code, it looks like pip is picking up the platform tag
>>>> through `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64'
>>>> on this machine. At root, I think this comes from
>>>> the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at
>>>> `python3.5/config-3.5m/Makefile`. I know that this value is used by
>>>> distutils compiling python extension modules -- presumably so that they can
>>>> be distributed to any target machine with OS X >=10.5 -- so that's good.
>>>> But is this the right thing for pip to be using when checking whether a
>>>> binary wheel is compatible? I see it mentioned
>>>> <https://www.python.org/dev/peps/pep-0425/#id13> in PEP 425, so
>>>> perhaps this was already hashed out on the list.
>>>>
>>>> Best,
>>>> Robert
>>>> ___
>>>> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

I don't think it's the sorting, per se. All of the get_supported() tags are
10.5 or earlier. Here's the output:
https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9


On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth  wrote:

> It should already be sorted. Try python -c "import pprint,
> pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"
>
> Do none of the tags for the available numpy wheels appear in that list?
>
> On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon  wrote:
>
>> Hi,
>>
>> I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it
>> proceeds to download and compile the tarball from PyPI from source (very
>> slow). I see, however, that pre-compiled OS X wheel files are available on
>> PyPI for OS X 10.6 and later.
>>
>> Checking the code, it looks like pip is picking up the platform tag
>> through `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64'
>> on this machine. At root, I think this comes from
>> the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at
>> `python3.5/config-3.5m/Makefile`. I know that this value is used by
>> distutils compiling python extension modules -- presumably so that they can
>> be distributed to any target machine with OS X >=10.5 -- so that's good.
>> But is this the right thing for pip to be using when checking whether a
>> binary wheel is compatible? I see it mentioned
>> <https://www.python.org/dev/peps/pep-0425/#id13> in PEP 425, so perhaps
>> this was already hashed out on the list.
>>
>> Best,
>> Robert
>> ___
>> 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] Platform tags for OS X binary wheels

[Robert McGibbon]

Hi,

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it
proceeds to download and compile the tarball from PyPI from source (very
slow). I see, however, that pre-compiled OS X wheel files are available on
PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag through
`distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on this
machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5
entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that this
value is used by distutils compiling python extension modules -- presumably
so that they can be distributed to any target machine with OS X >=10.5 --
so that's good. But is this the right thing for pip to be using when
checking whether a binary wheel is compatible? I see it mentioned
 in PEP 425, so perhaps
this was already hashed out on the list.

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

Re: [Distutils] The future of invoking pip

[Robert McGibbon]

Hi,

My perspective as a user of pip, but not a developer, is that having the
command line executable `pip` is much preferable to `python -m pip`. Most
of the use cases that militate against the command line executable seem to
be issues that face developers and ultra-power-users (keeping track of many
versions of pip installed, etc). But many casual users, I think, just have
one version of python/pip installed, and benefit from having the
easy-to-call executable. They're also the least capable of adding new
script wrappers and bash aliases.

Just my $0.02

Best,
-Robert

On Thu, Nov 5, 2015 at 6:49 PM, Glyph Lefkowitz 
wrote:

>
> On Nov 5, 2015, at 5:04 PM, Robert Collins 
> wrote:
>
> cat > /usr/bin/pip << EOF
> python -m pip $@
> EOF
>
> Seriously - isn't the above entirely sufficient?
>
>
> Since I don't think anyone has pointed this out yet:
>
> No, it's not sufficient.  It doesn't work on Windows.
>
> -glyph
>
>
> ___
> 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] Brian Goetz - Stewardship: the Sobering Parts

[Robert McGibbon]

Hi,

Thanks for sharing that video, Donald.

In context, I don't think it's fair to characterize the speaker's
perspective as *dangerous*, or of categorically favoring current users over
potential new users. Obviously there are a lot of tradeoffs around backward
compatibility, and no one-sized-fits-all solutions.

One of the most powerful points Brian made is that the large user base of
Java (or Python, etc) is an immensely powerful source of leverage. Each
incremental improvement to the language, standard library, or associated
tools will almost immediately impact a lot of users and improve their
lives. It's kind of an obvious point, but I think he expressed it very well.

On that note, I lurk on this list regularly, but generally don't really
contribute. I do see the awesome work that ya'll are putting in on a day to
day basis, and I see the results in the wild. Thanks to all of your hard
work, the packaging situation has vastly improved, and continues to do so,
especially with pip and wheels. All your hard work has definitely made my
life better, for one.

Best,
Robert

On Sun, Nov 1, 2015 at 3:12 PM, Nick Coghlan  wrote:

> On 31 October 2015 at 14:15, Wayne Werner  wrote:
> > First, do no harm, eh?
>
> I haven't had time to watch it yet so I don't have the full context of
> the observation, but that's only true if current users are considered
> categorically more important than future users. That's a dangerous
> line of thinking, as it means the cognitive burden of learning a
> language and ecosystem can only ever grow, and never shrink (since
> superseded concepts are never pruned from the set of things you need
> to learn, and you're also never really able to fix design mistakes
> resulting from limited perspectives in early iterations).
>
> Large scale migration projects like the shift away from implementation
> defined behaviour in the Python packaging ecosystem are cases where
> reducing barriers to entry for *new* users has edged out compatibility
> for existing users as a priority - the latter is still important, it's
> just acceptable for the level of compatibility to be less than 100%.
>
> Regards,
> Nick.
>
> P.S. From a medical perspective, there are certainly cases were
> doctors *do* inflict a lesser harm (e.g. amputations) to avoid a
> greater harm (e.g. death). "We saved the limb, but lost the patient"
> isn't one of the available options.
> ___
> 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] Python module for use in ‘setup.py’ but not to install

[Robert McGibbon]

> If you're just after the ability to say "I want to include this file in
the sdist, but not in the built wheel file or installed distribution" (as I
now believe you are)

I think that you can add the file to the MANIFEST.in file to achieve the
desired behavior.

-Robert

On Sun, Jan 18, 2015 at 11:39 PM, Nick Coghlan  wrote:

> On 19 January 2015 at 11:59, Ben Finney 
> wrote:
> > Nick Coghlan  writes:
> >
> >> If you have a build/install time only dependency that you want to
> >> distribute, you *have* to separate it out into a separate component if
> >> you don't want it to also be present at runtime.
> >
> > So, to be clear: if this module is needed during build-time for the
> > distribution but does not have a stable API yet, you're saying it
> > nevertheless needs to go to a repository for download as an independent
> > distribution?
>
> I actually misunderstood your question. If you're just after the
> ability to say "I want to include this file in the sdist, but not in
> the built wheel file or installed distribution" (as I now believe you
> are), then you're in the implementation defined world of the
> significantly underspecified sdist format. I believe setting that up
> actually *is* possible already, but have no idea what incantation
> you'll need to pass to setuptools to make it do it (and the docs are
> unlikely to be a reliable guide).
>
> If you'd like to volunteer for the task of reverse engineering and
> properly documenting how sdists work (with regression tests!), that
> would be quite awesome. Not necessarily *fun* from your point of view,
> but definitely awesome from my point of view :)
>
> 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-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig