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

Request for acces to salsa project

[eamanu15]

Hello everybody,

I resend this mail.

I was maintaining pygtihub project (
https://salsa.debian.org/python-team/modules/pygithub/)

But, I lost my privileges when the project was migrate to salsa. Could you
give me access to pygithub?

I have some commits.

My salsa user is: eamanu-guest

Thanks very much!
Regards!
-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

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)

How to make sure PATH is set correctly (Was: foo FTBFS with dh-python >= 3.20180313)

[Andreas Tille]

Hi again,

sorry for nagging again but what else than I did in

   https://salsa.debian.org/med-team/snakemake/blob/master/debian/rules

can I do to set PATH in pbuilder.  Possibly I've understand all your
hints incorrectly - the PATH is just not set inside pbuilder chroot. :-(

Kind regards

 Andreas.

On Mon, Apr 30, 2018 at 11:13:44PM +0200, Andreas Tille wrote:
> On Mon, Apr 30, 2018 at 08:29:13PM +0200, Piotr Ożarowski wrote:
> > [Andreas Tille, 2018-04-30]
> > > Hmmm, inside pbuilder chroot the files are installed to
> > > 
> > >   
> > > /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build/bin/snakemake
> > > 
> > > while
> > > 
> > >   # pybuild --print build_dir --interpreter python3
> > >   /build/snakemake-4.8.0/.pybuild/cpython3_3.6/build
> > 
> > you invoked it outside debian/rules, without --name or PYBUILD_NAME set,
> > right?
> 
> Yes, that's right.
>  
> > > I have no idea why since some dh-python version things are different
> > > than before but wouldn't it be the best idea to let pybuild set PATH and
> > > PYTHONPATH instead of setting it manually by some manual command?
> > 
> > I meant to fix also debian/rules line 11 (you fixed line 21 only)
> 
> I commited my last attemt to Git fixing PATH on both lines.
> 
> I get with this d/rules:
> 
> 
> ...
> raise Exception("snakemake not in PATH. For testing, install snakemake 
> with "
> Exception: snakemake not in PATH. For testing, install snakemake with 'pip 
> install -e .'. You should do this in a separate environment (via conda or 
> virtualenv).
> 
> --
> Ran 4 tests in 0.187s
> 
> FAILED (errors=1)
> E: pybuild pybuild:336: test: plugin distutils failed with: exit code=1: cd 
> /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build; python3.6 -m 
> nose tests
> dh_auto_test: pybuild --test --test-nose -i python{version} -p 3.6 returned 
> exit code 13
> make: *** [debian/rules:17: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> I: copying local configuration
> E: Failed autobuilding of package
> I: user script /var/cache/pbuilder/build/cow.11501/tmp/hooks/C99_failed_build 
> starting
> root:/# echo $PATH
> /usr/sbin:/usr/bin:/sbin:/bin
> 
> 
> I have no idea why but the PATH does not make it through.
> 
> I confirm if I set
> 
>root:/build/snakemake-4.8.0# export PYBUILD_NAME=snakemake
>root:/build/snakemake-4.8.0# pybuild --print build_dir --interpreter 
> python3
>/build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build
> 
> But why does these variables not end up in the chroot?
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: input into perl 6 packaging required

[Dmitry Shachnev]

Hi Robert!

On Sat, May 05, 2018 at 09:21:28PM +0200, Robert Lemmen wrote:
> hi folks,
>
> we are currently thinking about how to package perl 6 modules, some
> background and information at https://wiki.debian.org/Perl6PreCompProposal
>
> Perl 6 does pre-compile modules on loading, a bit like the .pyc files.
> So I would be very glad if you could have a quick look at the wiki page
> above, perhaps you experience could help us. I am also specifically
> interested in your decision to create the .pyc files at package
> installation time, rather than at package build time. What was the
> reason for that? Do you still think it was the right decision? In the
> case of perl 6 the precompiled files depend on a fairly specific version
> of the runtime, so we would need to re-build them quite often...

I think the main reasons for generating .pyc files at install time were:

- Ability to ship “Architecture: all” packages, which reduces load on
  build daemons, mirrors, etc.

- Ability to regenerate all .pyc files for new Python version on users’
  side (it does not take a long time), without need to do binNMUs or
  re-uploads.

And I think it was the right decision, as these reasons still apply.

--
Dmitry Shachnev


signature.asc
Description: PGP signature