Re: Removal of easy_install

[Matthias Klose]

On 07.05.2018 03:39, Scott Talbert wrote:
> About a month ago, Matthias removed easy_install from setuptools.  I have sent
> him a few mails and bugs asking about it, but I haven't heard anything back. 
> Anyone know why he did it?  I have a package that currently FTBFS because of
> it.  :(
> 
> python-setuptools (39.0.1-2) unstable; urgency=medium
> 
>   * Make the PKG-INFO output reproducible (Chris Lamb). Closes: #894215.
>   * Stop shipping the easy_install scripts.
> 
>  -- Matthias Klose   Mon, 02 Apr 2018 11:46:01 +0200

easy_install isn't the preferred method to install things anymore, but you you
still can use python3 -m easy_install if you still need to use it.

Re: Removal of easy_install

[Ben Finney]

Scott Talbert  writes:

> Installing the egg means that all the wxpython4.0 files are installed
> under:
> /usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
>
> Thus, any program or user who does an 'import wx' will get the
> wxpython3.0 module and if instead the wxpython4.0 module is desired,
> the user must manually insert the above path into sys.path or
> PYTHONPATH.

That seems, based on the above description, to just arbitrarily declare
one version to be the default, and the other needs manual override by
the user.

If that's an accurate description of the effect you want, then you don't
need to do a special ‘easy_install’ usage, nor an Egg install. You can
instead install to a different location using the normal tools. See the
‘pybuild(1)’ manual page on how to specify installation locations when
installing the Python library.

That would not need anything different from the Debian package tools,
and you are then left in the same situation: the user needs to specify a
different import search path to choose the different library.

-- 
 \  “By instructing students how to learn, unlearn, and relearn, a |
  `\ powerful new dimension can be added to education.” —Alvin |
_o__)Toffler, _Future Shock_, 1970 |
Ben Finney

Re: Removal of easy_install

[Scott Talbert]

On Tue, 8 May 2018, Ben Finney wrote:


The source package in question is wxpython4.0. The reason I use
easy_install is for installing the python2 version of the module as an
egg.


Okay, so from that I understand that the Debian package is not invoking
‘easy_install’ to fetch files from the network.


From what I remember, it is surprisingly difficult to convince

‘easy_install’ that it should never access the network, even when you
think you're only performing local operations. Probably it's best to
test this in a virtual machine isolated from the network, to be sure it
succeeds.


Correct - using easy_install to install the egg doesn't fetch files from 
the network.  I haven't tried this in a virtual machine, but it definitely 
works fine on the Fedora builders which are pretty well hardened to have 
no network access.



The reason I do this is because wxpython3.0 occupies the 'namespace'
for the wx module for python2. In other words, both wxpython3.0 and
wxpython4.0 have a 'wx' module for python2. In order to avoid a
conflict, I install the wxpython4.0 version as an egg.


How does that avoid the conflict — that is, what is the effect of
installing the egg such that a namespace conflict is avoided?

I ask because it is likely that today's Python has a better way of
achieving the effect you're wanting, so that ‘easy_install’ is not
needed.


Installing the egg means that all the wxpython4.0 files are installed 
under:

/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg

Thus, any program or user who does an 'import wx' will get the wxpython3.0 
module and if instead the wxpython4.0 module is desired, the user must 
manually insert the above path into sys.path or PYTHONPATH.


Scott

Re: Removal of easy_install

[Ben Finney]

Scott Talbert  writes:

> The source package in question is wxpython4.0. The reason I use
> easy_install is for installing the python2 version of the module as an
> egg.

Okay, so from that I understand that the Debian package is not invoking
‘easy_install’ to fetch files from the network.

>From what I remember, it is surprisingly difficult to convince
‘easy_install’ that it should never access the network, even when you
think you're only performing local operations. Probably it's best to
test this in a virtual machine isolated from the network, to be sure it
succeeds.

> The reason I do this is because wxpython3.0 occupies the 'namespace'
> for the wx module for python2. In other words, both wxpython3.0 and
> wxpython4.0 have a 'wx' module for python2. In order to avoid a
> conflict, I install the wxpython4.0 version as an egg.

How does that avoid the conflict — that is, what is the effect of
installing the egg such that a namespace conflict is avoided?

I ask because it is likely that today's Python has a better way of
achieving the effect you're wanting, so that ‘easy_install’ is not
needed.

-- 
 \“If we ruin the Earth, there is no place else to go. This is |
  `\not a disposable world, and we are not yet able to re-engineer |
_o__)  other planets.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney

Re: Removal of easy_install

[Scott Talbert]

On Mon, 7 May 2018, Ben Finney wrote:


About a month ago, Matthias removed easy_install from setuptools.  I
have sent him a few mails and bugs asking about it, but I haven't
heard anything back.  Anyone know why he did it?  I have a package
that currently FTBFS because of it.  :(


Why does a source package *build* need to use ‘easy_install’? The source
package should not need any network access to build, all the source
should be in Debian source packages that are fetched before the build
begins.

Which package is the one that's failing to build now?


I guess I should have included that information.  :)

The source package in question is wxpython4.0.  The reason I use 
easy_install is for installing the python2 version of the module as an 
egg.  The reason I do this is because wxpython3.0 occupies the 'namespace' 
for the wx module for python2.  In other words, both wxpython3.0 and 
wxpython4.0 have a 'wx' module for python2.  In order to avoid a conflict, 
I install the wxpython4.0 version as an egg.  The wxpython3.0 and 
wxpython4.0 modules are not drop-in compatible, so an update-alternatives 
solution doesn't make sense.


Scott

Re: Removal of easy_install

[Thomas Goirand]

On 05/07/2018 04:19 AM, Ben Finney wrote:
> Scott Talbert  writes:
> 
>> About a month ago, Matthias removed easy_install from setuptools.  I
>> have sent him a few mails and bugs asking about it, but I haven't
>> heard anything back.  Anyone know why he did it?  I have a package
>> that currently FTBFS because of it.  :(
> 
> Why does a source package *build* need to use ‘easy_install’? The source
> package should not need any network access to build, all the source
> should be in Debian source packages that are fetched before the build
> begins.
> 
> Which package is the one that's failing to build now?

I agree with the above. Never the less, I don't see why we wouldn't ship
easy_install anymore, it's still useful (outside of packaging).

Cheers,

Thomas Goirand (zigo)

Re: Removal of easy_install

[Ben Finney]

Scott Talbert  writes:

> About a month ago, Matthias removed easy_install from setuptools.  I
> have sent him a few mails and bugs asking about it, but I haven't
> heard anything back.  Anyone know why he did it?  I have a package
> that currently FTBFS because of it.  :(

Why does a source package *build* need to use ‘easy_install’? The source
package should not need any network access to build, all the source
should be in Debian source packages that are fetched before the build
begins.

Which package is the one that's failing to build now?

-- 
 \   “I prayed for twenty years but received no answer until I |
  `\  prayed with my legs.” —Frederick Douglass, escaped slave |
_o__)  |
Ben Finney