Re: [Distutils] latest setuptools appears to require six in a breaking way

[Matthew Brett]

Hi,

On Wed, Jan 25, 2017 at 4:52 PM, Donald Stufft  wrote:
>
> On Jan 25, 2017, at 12:27 PM, Eric Brunson  wrote:
>
> It wasn't until recently the I realized how quickly releases to setuptools
> and pip are being made, starting back in mid Dec when much of our dependency
> resolution started failing.  There were three releases in the past two days.
> Four major and 22 minor releases in the past two months.  While I applaud
> the speed of development and the improvement in these tools, don't you feel
> that breaking changes should be advertised better before release or perhaps
> we should slow down the cadence for release?
>
> I think an expectation that every setuptools user in the community start
> their day by checking to see if there was a release in the past 24 hours is
> a little unreasonable.  I've spent a dozen hours since 32.0.0 resolving
> breakage in my own projects and assisting other developers in my org with
> their setuptools issues, all the while pushing setuptools as the best
> practice to do development and distribution.  Is this period of breaking
> changes a short term thing that we just have to tough out for a few more
> weeks?
>
> Thanks,
> e.
>
>
>
> I don’t believe that pip is really releasing that quickly. We generally make
> 1-2 “major” versions a year that include breaking changes, 2-4 “minor”
> releases a year that add new features, and 6-10 patch releases that fix
> bugs. To me that feels like a pretty decent pace of balancing not breaking
> people and getting new changes into people’s hands and getting rid of broken
> or less optimal parts of the code.
>
> Now, setuptools is releasing faster than pip is and whether that’s a good
> thing or not I don’t know. That’s a question for Jason largely :)

It sounds like we need to get some continuous integration to bear on
this problem.

How about the following suggestion: before new releases, make release
candidates for pip, wheel, setuptools and virtualenv, upload to pypi,
announce here.

Then we the dependent projects can have a continuous integration entry
which tests our normal pip install with the --pre versions of these
packages, to screen for trouble.   I think that would catch many of
the problems, and it doesn't seem like it would be much work for the
package maintainers.

Cheers,

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

Re: [Distutils] latest setuptools appears to require six in a breaking way

[Donald Stufft]

> On Jan 25, 2017, at 12:27 PM, Eric Brunson  wrote:
> 
> It wasn't until recently the I realized how quickly releases to setuptools 
> and pip are being made, starting back in mid Dec when much of our dependency 
> resolution started failing.  There were three releases in the past two days.  
> Four major and 22 minor releases in the past two months.  While I applaud the 
> speed of development and the improvement in these tools, don't you feel that 
> breaking changes should be advertised better before release or perhaps we 
> should slow down the cadence for release?
> 
> I think an expectation that every setuptools user in the community start 
> their day by checking to see if there was a release in the past 24 hours is a 
> little unreasonable.  I've spent a dozen hours since 32.0.0 resolving 
> breakage in my own projects and assisting other developers in my org with 
> their setuptools issues, all the while pushing setuptools as the best 
> practice to do development and distribution.  Is this period of breaking 
> changes a short term thing that we just have to tough out for a few more 
> weeks?
> 
> Thanks,
> e.
> 


I don’t believe that pip is really releasing that quickly. We generally make 
1-2 “major” versions a year that include breaking changes, 2-4 “minor” releases 
a year that add new features, and 6-10 patch releases that fix bugs. To me that 
feels like a pretty decent pace of balancing not breaking people and getting 
new changes into people’s hands and getting rid of broken or less optimal parts 
of the code.

Now, setuptools is releasing faster than pip is and whether that’s a good thing 
or not I don’t know. That’s a question for Jason largely :)


—
Donald Stufft



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

Re: [Distutils] latest setuptools appears to require six in a breaking way

[Eric Brunson]

It wasn't until recently the I realized how quickly releases to setuptools
and pip are being made, starting back in mid Dec when much of our
dependency resolution started failing.  There were three releases in the
past two days.  Four major and 22 minor releases in the past two months.
While I applaud the speed of development and the improvement in these
tools, don't you feel that breaking changes should be advertised better
before release or perhaps we should slow down the cadence for release?

I think an expectation that every setuptools user in the community start
their day by checking to see if there was a release in the past 24 hours is
a little unreasonable.  I've spent a dozen hours since 32.0.0 resolving
breakage in my own projects and assisting other developers in my org with
their setuptools issues, all the while pushing setuptools as the best
practice to do development and distribution.  Is this period of breaking
changes a short term thing that we just have to tough out for a few more
weeks?

Thanks,
e.

On Wed, Jan 25, 2017 at 9:45 AM Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:

> AFAICT this is not really an issue as this is on the release notes:
>
> https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0
>
> You need to upgrade pip  (cf 3rd paragraph):
>
> > #581: Instead of vendoring the growing list of dependencies that
> Setuptools requires to function, Setuptools now requires these dependencies
> just like any other project. Unlike other projects, however, Setuptools
> cannot rely on setup_requires to demand the dependencies it needs to
> install because its own machinery would be necessary to pull those
> dependencies if not present (a bootstrapping problem). As a result,
> Setuptools no longer supports self upgrade or installation in the general
> case. Instead, users are directed to use pip to install and upgrade using
> the wheel distributions of setuptools.
>
> > Users are welcome to contrive other means to install or upgrade
> Setuptools using other means, such as pre-installing the Setuptools
> dependencies with pip or a bespoke bootstrap tool, but such usage is not
> recommended and is not supported.
>
>  >As discovered in #940, not all versions of pip will successfully
> install Setuptools from its pre-built wheel. If you encounter issues
> with “No module named six” or “No module named packaging”, especially
> following a line “Running setup.py egg_info for package setuptools”,
> then your pip is not new enough.
>
> > There’s an additional issue in pip where setuptools is upgraded
> concurrently with other source packages, described in pip #4253. The
> proposed workaround is to always upgrade Setuptools first prior to
> upgrading other packages that would upgrade Setuptools.
>
> --
> M
>
> On Wed, Jan 25, 2017 at 6:46 AM, Robin Becker  wrote:
> >
> > On 25/01/2017 10:41, Chris Withers wrote:
> >>
> >> Hi All,
> >>
> >> Anyone else seen this?
> >>
> >> |File
> >>
> >>
> "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py",
> >> line 10, in  from six.moves import filter, map ImportError: No
> >> module
> >> named six.moves|
> >>
> > My colleague just came across this when creating a new venv.
> >
> > We then installed six, but our setup then went on to complain about
> > packaging and then finally appdirs before it went through.
> >
> > Each time the fix was to manually install the thing that pip complained
> > about.
> >
> >
> >>
> >> Started happening in my nightly builds on travis after the 34.0.2
> release
> >> of
> >> setuptools. I've filed an issue here since I suspect it isn't just me:
> >>
> >> https://github.com/pypa/setuptools/issues/945
> >>
> >> cheers,
> >>
> >> Chris
> >>
> >>
> >>
> >> ___
> >> Distutils-SIG maillist  -  Distutils-SIG@python.org
> >> https://mail.python.org/mailman/listinfo/distutils-sig
> >>
> >
> >
> > --
> > Robin Becker
> > ___
> > 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] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Paul Moore]

On 25 January 2017 at 21:26, Thomas Kluyver  wrote:
> On Wed, Jan 25, 2017, at 09:02 PM, Paul Moore wrote:
>> Thanks. I've been seeing the PR comments in passing, but haven't
>> really looked in detail. Is there anything I can do to help this
>> along?
>
> I believe it's working, but it's the first significant change I've made
> in pip, so any review is welcome.

Cool - I'll try to make some time, maybe over the weekend.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Thomas Kluyver]

On Wed, Jan 25, 2017, at 09:02 PM, Paul Moore wrote:
> Thanks. I've been seeing the PR comments in passing, but haven't
> really looked in detail. Is there anything I can do to help this
> along?

I believe it's working, but it's the first significant change I've made
in pip, so any review is welcome.

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

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Paul Moore]

On 25 January 2017 at 20:04, Thomas Kluyver  wrote:
> On Wed, Jan 25, 2017, at 08:02 PM, Donald Stufft wrote:
>
> Since we have a PR up for PEP 518 already,
>
>
> Here's the link if anyone wants to take a look:
> https://github.com/pypa/pip/pull/4144

Thanks. I've been seeing the PR comments in passing, but haven't
really looked in detail. Is there anything I can do to help this
along?

If Donald is looking at "the next release of pip" for this (and
virtualenv will presumably be released in sync, as usual) there's not
much point doing anything shorter term than that for virtualenv, so it
looks like option (3) it is :-)

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

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Thomas Kluyver]

On Wed, Jan 25, 2017, at 08:02 PM, Donald Stufft wrote:

> Since we have a PR up for PEP 518 already, 



Here's the link if anyone wants to take a look:

https://github.com/pypa/pip/pull/4144


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

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Donald Stufft]

> On Jan 25, 2017, at 3:00 PM, Paul Moore  wrote:
> 
> On 25 January 2017 at 19:15, Donald Stufft  wrote:
>> If we get PEP 518 landed in pip I think that (3) is the right step forward.
> 
> Agreed. With that in mind (do we have any timescale for that work?) I
> suggest we do (4) for now and switch to (3) once PEP 518 is in place.
> Paul


Since we have a PR up for PEP 518 already, I hope to make sure it lands in the 
next release of pip. I’d likely go as far to say that as soon as it lands I’ll 
probably release pip again. Beyond that I don’t have a specific timescale.

—
Donald Stufft



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

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Paul Moore]

On 25 January 2017 at 19:15, Donald Stufft  wrote:
> If we get PEP 518 landed in pip I think that (3) is the right step forward.

Agreed. With that in mind (do we have any timescale for that work?) I
suggest we do (4) for now and switch to (3) once PEP 518 is in place.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Donald Stufft]

> On Jan 25, 2017, at 2:11 PM, Paul Moore  wrote:
> 
> On 25 January 2017 at 17:20, Chris Withers  wrote:
>> Right, so what's the recommended one-step way to set up a virtualenv now in
>> Py 2.6-3.6?
> 
> This is the point I would consider most significant here. Virtualenv
> is deliberately built to allow use offline - pip, wheel and setuptools
> are bundled so that it's possible to create a virtualenv without
> needing Internet access. This change to setuptools will, if I
> understand it, break that expectation.
> 
> While it's not a common scenario, I think it's something that should
> be considered. Going forward, I see a number of options for
> virtualenv:
> 
> 1. Bundle all of setuptools' dependencies as well.
> 2. Drop the "no internet required" constraint - if we do this, it may
> be reasonable to only bundle pip, and get latest versions of
> everything else from PyPI.
> 3. Drop auto-installing setuptools (it's not needed unless you're
> installing from sdist, and it's only a "pip install setuptools" away
> for people who need it).
> 4. Document the changed behaviour by saying that no internet is
> required as long as you use --no-setuptools.
> 
> Thoughts, anyone? Is the situation common enough to warrant anything
> other than (4)? It used to be for me, when pip didn't cache downloads
> and I had a secured proxy to deal with, but now I'd be OK with (4).
> 

If we get PEP 518 landed in pip I think that (3) is the right step forward.

—
Donald Stufft



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

[Distutils] Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]

[Paul Moore]

On 25 January 2017 at 17:20, Chris Withers  wrote:
> Right, so what's the recommended one-step way to set up a virtualenv now in
> Py 2.6-3.6?

This is the point I would consider most significant here. Virtualenv
is deliberately built to allow use offline - pip, wheel and setuptools
are bundled so that it's possible to create a virtualenv without
needing Internet access. This change to setuptools will, if I
understand it, break that expectation.

While it's not a common scenario, I think it's something that should
be considered. Going forward, I see a number of options for
virtualenv:

1. Bundle all of setuptools' dependencies as well.
2. Drop the "no internet required" constraint - if we do this, it may
be reasonable to only bundle pip, and get latest versions of
everything else from PyPI.
3. Drop auto-installing setuptools (it's not needed unless you're
installing from sdist, and it's only a "pip install setuptools" away
for people who need it).
4. Document the changed behaviour by saying that no internet is
required as long as you use --no-setuptools.

Thoughts, anyone? Is the situation common enough to warrant anything
other than (4)? It used to be for me, when pip didn't cache downloads
and I had a secured proxy to deal with, but now I'd be OK with (4).

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

Re: [Distutils] latest setuptools appears to require six in a breaking way

[Matthias Bussonnier]

> Just because it's on the release notes doesn't mean its not an issue.

Sorry if I miss expressed myself, let me retry:

If it is on the release notes, then it is likely because the
maintainers are aware. And if they released this version with this in
the release notes, then trying to fill a bug will likely result in it
being dismissed as duplicate.
I tried to be too concise.

I don't disagree that this change is likely to be quite painful, and I
have not contributed enough to setuptools to contradict the choice the
maintainers have had. I just linked to (and cited) the release notes,
gave a reason as I was aware (since yesterday, made /r/python top 10)
of why you were seeing what you are seeing.

I do understand the difficulty to upgrade all the CI script and
library. I've been in the process of upgrading our test suite and test
of all the packages I maintain to make sure we don't use
DeprecatedBehavior of 3.6 (Oh invalid backslash escape sequence is fun
in docstring that give example with windows Path). So yes that a
couple of weeks of low productivity. But at the same time that's the
price I chose to pay to support such a wide range of versions and have
sofware from 2 differents decades to work together.

I want to add that if your system is still using old pip/setuptools
version then it might soon break for other reasons. Setuptools < 24
(IIRC) and pip < 9 cannot handle Python 3 only Sdist correctly. So if
one of your libraries you use publish a Python 3 only sdist (which is
likely to happen at some point in time) then your CI will install the
latest python 3 only sdist on python 2 instead of the latest Python 2
compatible sdist. Which is likely to fail as well.

So at some point upgrading pip and setuptools as a first step of CI
integration might be anyway necessary.

Hope this problem will be either accepted or solved soon.

Thanks
-- 
M





On Wed, Jan 25, 2017 at 9:20 AM, Chris Withers  wrote:
> On 25/01/2017 16:44, Matthias Bussonnier wrote:
>>
>> AFAICT this is not really an issue as this is on the release notes:
>>
>> https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0
>
>
> Just because it's on the release notes doesn't mean its not an issue.
>
>>> #581: Instead of vendoring the growing list of dependencies that
>>> Setuptools requires to function, Setuptools now requires these dependencies
>>> just like any other project. Unlike other projects, however, Setuptools
>>> cannot rely on setup_requires to demand the dependencies it needs to install
>>> because its own machinery would be necessary to pull those dependencies if
>>> not present (a bootstrapping problem). As a result, Setuptools no longer
>>> supports self upgrade or installation in the general case. Instead, users
>>> are directed to use pip to install and upgrade using the wheel distributions
>>> of setuptools.
>
>
> For such a fundamental part of the python packaging ecosystem, that's a
> pretty disappointing change. Not supporting self-upgrade seems like a pretty
> massive regression, and the problems here are a result.
>
> None of the problems I've had involve explicit installation of setuptools,
> it seems to be dragged in as a dependency somewhere along the way. The lack
> of ability to self-update in that situation is going to cause major pain.
>
>>  >As discovered in #940, not all versions of pip will successfully
>> install Setuptools from its pre-built wheel. If you encounter issues
>> with “No module named six” or “No module named packaging”, especially
>> following a line “Running setup.py egg_info for package setuptools”,
>> then your pip is not new enough.
>
>
> Right, so what's the recommended one-step way to set up a virtualenv now in
> Py 2.6-3.6?
>
>>> There’s an additional issue in pip where setuptools is upgraded
>>> concurrently with other source packages, described in pip #4253. The
>>> proposed workaround is to always upgrade Setuptools first prior to upgrading
>>> other packages that would upgrade Setuptools.
>
>
> That workaround is quite painful if you maintain any number of libraries
> that have CI scripts that will need to be hacked up to support the
> workaround and then reverted after the issue is finally fixed.
>
> Sorry if this comes across as negative, I know it's not always easy to judge
> the outcome of changes before a big release, but I do hope something can be
> done to mitigate the pain of library maintainers doing the right thing and
> running CI...
>
> cheers,
>
> Chris
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Enquire for python

[Brett Cannon]

Instructions can be found at https://packaging.python.org/installing/

On Wed, 25 Jan 2017 at 03:42 ali refaee  wrote:

> Dear Sir/Madam
> I’m beginner in python, how can I get python modules?
> when run some function
> such as (import numpy as np)
> message
> ImportError: No module named numpy
>
> another ex
> import matplotlib.pyplot as plt
> ImportError: No module named matplotlib.pyplot
>
> how we  install modules?
> where are the modules?
> can I get modules to run python?
>
> Sent from Windows Mail
>
> ___
> 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] latest setuptools appears to require six in a breaking way

[Chris Withers]

On 25/01/2017 16:44, Matthias Bussonnier wrote:

AFAICT this is not really an issue as this is on the release notes:

https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0


Just because it's on the release notes doesn't mean its not an issue.


#581: Instead of vendoring the growing list of dependencies that Setuptools 
requires to function, Setuptools now requires these dependencies just like any 
other project. Unlike other projects, however, Setuptools cannot rely on 
setup_requires to demand the dependencies it needs to install because its own 
machinery would be necessary to pull those dependencies if not present (a 
bootstrapping problem). As a result, Setuptools no longer supports self upgrade 
or installation in the general case. Instead, users are directed to use pip to 
install and upgrade using the wheel distributions of setuptools.


For such a fundamental part of the python packaging ecosystem, that's a 
pretty disappointing change. Not supporting self-upgrade seems like a 
pretty massive regression, and the problems here are a result.


None of the problems I've had involve explicit installation of 
setuptools, it seems to be dragged in as a dependency somewhere along 
the way. The lack of ability to self-update in that situation is going 
to cause major pain.



 >As discovered in #940, not all versions of pip will successfully
install Setuptools from its pre-built wheel. If you encounter issues
with “No module named six” or “No module named packaging”, especially
following a line “Running setup.py egg_info for package setuptools”,
then your pip is not new enough.


Right, so what's the recommended one-step way to set up a virtualenv now 
in Py 2.6-3.6?



There’s an additional issue in pip where setuptools is upgraded concurrently 
with other source packages, described in pip #4253. The proposed workaround is 
to always upgrade Setuptools first prior to upgrading other packages that would 
upgrade Setuptools.


That workaround is quite painful if you maintain any number of libraries 
that have CI scripts that will need to be hacked up to support the 
workaround and then reverted after the issue is finally fixed.


Sorry if this comes across as negative, I know it's not always easy to 
judge the outcome of changes before a big release, but I do hope 
something can be done to mitigate the pain of library maintainers doing 
the right thing and running CI...


cheers,

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

Re: [Distutils] latest setuptools appears to require six in a breaking way

[Matthias Bussonnier]

AFAICT this is not really an issue as this is on the release notes:

https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0

You need to upgrade pip  (cf 3rd paragraph):

> #581: Instead of vendoring the growing list of dependencies that Setuptools 
> requires to function, Setuptools now requires these dependencies just like 
> any other project. Unlike other projects, however, Setuptools cannot rely on 
> setup_requires to demand the dependencies it needs to install because its own 
> machinery would be necessary to pull those dependencies if not present (a 
> bootstrapping problem). As a result, Setuptools no longer supports self 
> upgrade or installation in the general case. Instead, users are directed to 
> use pip to install and upgrade using the wheel distributions of setuptools.

> Users are welcome to contrive other means to install or upgrade Setuptools 
> using other means, such as pre-installing the Setuptools dependencies with 
> pip or a bespoke bootstrap tool, but such usage is not recommended and is not 
> supported.

 >As discovered in #940, not all versions of pip will successfully
install Setuptools from its pre-built wheel. If you encounter issues
with “No module named six” or “No module named packaging”, especially
following a line “Running setup.py egg_info for package setuptools”,
then your pip is not new enough.

> There’s an additional issue in pip where setuptools is upgraded concurrently 
> with other source packages, described in pip #4253. The proposed workaround 
> is to always upgrade Setuptools first prior to upgrading other packages that 
> would upgrade Setuptools.

-- 
M

On Wed, Jan 25, 2017 at 6:46 AM, Robin Becker  wrote:
>
> On 25/01/2017 10:41, Chris Withers wrote:
>>
>> Hi All,
>>
>> Anyone else seen this?
>>
>> |File
>>
>> "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py",
>> line 10, in  from six.moves import filter, map ImportError: No
>> module
>> named six.moves|
>>
> My colleague just came across this when creating a new venv.
>
> We then installed six, but our setup then went on to complain about
> packaging and then finally appdirs before it went through.
>
> Each time the fix was to manually install the thing that pip complained
> about.
>
>
>>
>> Started happening in my nightly builds on travis after the 34.0.2 release
>> of
>> setuptools. I've filed an issue here since I suspect it isn't just me:
>>
>> https://github.com/pypa/setuptools/issues/945
>>
>> cheers,
>>
>> Chris
>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
> --
> Robin Becker
> ___
> 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] latest setuptools appears to require six in a breaking way

[Robin Becker]

On 25/01/2017 10:41, Chris Withers wrote:

Hi All,

Anyone else seen this?

|File
"/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py",
line 10, in  from six.moves import filter, map ImportError: No module
named six.moves|


My colleague just came across this when creating a new venv.

We then installed six, but our setup then went on to complain about packaging 
and then finally appdirs before it went through.


Each time the fix was to manually install the thing that pip complained about.




Started happening in my nightly builds on travis after the 34.0.2 release of
setuptools. I've filed an issue here since I suspect it isn't just me:

https://github.com/pypa/setuptools/issues/945

cheers,

Chris



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




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

[Distutils] Enquire for python

[ali refaee]

Dear Sir/Madam
I’m beginner in python, how can I get python modules?
when run some function
such as (import numpy as np)
message
ImportError: No module named numpy

another ex
import matplotlib.pyplot as plt
ImportError: No module named matplotlib.pyplot

how we  install modules?
where are the modules?
can I get modules to run python?

Sent from Windows Mail

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

Re: [Distutils] recommended strategy for missing development tools

[Thomas Kluyver]

On Wed, Jan 25, 2017, at 10:23 AM, Robin Becker wrote:
> The setup.py in question complains if the
> extension files cannot be found, but does not error.

There was a change in pip at some point which means that it only shows
the output from setup.py if running it fails (i.e. it has a non-zero
exit status). I think this was largely because setup.py output is much
more verbose than you usually want, especially if pip installs many
packages at once.

It's nice in some cases where setup.py displays warnings that aren't
really a problem. In one project I maintain, a particular submodule
requires Python 3, while the rest of the code can be used on Python 2 as
well; people with older versions of pip have complained that it 'fails
to install', which it doesn't, because the warning looks like a fatal
error.

However, the flip side of this is that, as far as I know, setup.py has
to choose between succeeding silently, or failing and showing the user
an error message.

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

[Distutils] latest setuptools appears to require six in a breaking way

[Chris Withers]

Hi All,

Anyone else seen this?

|File 
"/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py", 
line 10, in  from six.moves import filter, map ImportError: No 
module named six.moves|



Started happening in my nightly builds on travis after the 34.0.2 
release of setuptools. I've filed an issue here since I suspect it isn't 
just me:


https://github.com/pypa/setuptools/issues/945

cheers,

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

Re: [Distutils] recommended strategy for missing development tools

[Robin Becker]

On 24/01/2017 11:13, Nathaniel Smith wrote:

On Tue, Jan 24, 2017 at 3:09 AM, Robin Becker  wrote:

A reportlab user says his pip install fails to create an importable C
extension. He said

"The platform is Mac OS X 10.11.6, aka "El Capitan". Pip didn't complain"

which is probably true since the extension is not required for reportlab's
main usage.

I tried to reproduce on OS X 10.10.5, but my machine has xcode installed and
the extension was correctly produced.

I don't have any code in setup.py to prevent compilation; is there a way to
alert users to the non-build of the extension(s).


I'm having some trouble figuring out exactly what you're asking... is
the question: "if my setup.py encounters a non-fatal error while being
run by pip, how can I print a message for the user to see while still
letting the build continue?"?

-n

Sorry to be so vague, but I am not the person who ran pip install so I'm not 
exactly sure what happened. The setup.py in question complains if the extension 
files cannot be found, but does not error. If the files can be found and I 
assume they can because they're now part of the same repository then the 
extensions are set up and added to the final setup call. Since pip did not 
complain I assume either the setup.py failed to find the extension source or the 
compile failed silently somehow.


Unfortunately I don't have a test system where I can turn off xcode to see what 
happens. I'm wondering if setup fails silently somehow.

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

[Distutils] latest setuptools appears to require six in a breaking way

[Chris Withers]

Hi All,

Anyone else seen this?

|File 
"/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py", 
line 10, in  from six.moves import filter, map ImportError: No 
module named six.moves|



Started happening in my nightly builds on travis after the 34.0.2 
release of setuptools. I've filed an issue here since I suspect it isn't 
just me:


https://github.com/pypa/setuptools/issues/945

cheers,

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