Python conflicts.

Python conflicts.

[Ricardo Wurmus]

Hi Guix,

there are two things related to the installation of Python modules that
I would like to see changed; but as I may not understand what side
effects the proposed changes might have I'd like to gather some opinions
first.

1) Nosetests

Installing Python modules that have an input "python-nose" (always?)
install "$out/bin/nosetests" and various wrappers around this script.
This script is not very useful for a user of the module as it only runs
the test suite.  As we're often propagating Python module inputs, the
installation of one Python module usually results in conflicts with the
various versions of "$out/bin/nosetests" that are to be installed into
the profile.

This makes the nosetests scripts even less useful as an arbitrary
version will end up in the profile.  I'd like to exclude them from
installation in all Python packages, maybe by modifying
"python-build-system" such that the files are deleted from the output
directory again.

What I don't like about using the "python-build-system" for this is that
"$out/bin/nosetests" is only created when "python-nose" (or
"python2-nose") is a package input.  Is there a better way?  Can we
prevent the creation of the "nosetests" script (and its wrappers), maybe
with some flag to setuptools?

2) lib/python$version/site-packages/site.{py,pyc}

Another file that frequently causes conflicts is "site.py" (and its
compiled cousin).  It seems to me that "site.py" doesn't contain any
module-specific information and is probably the same for all modules.  I
would like to change "python-build-system" such that Python modules do
not install this file at all.

The only problem I see is that the "python" package itself does not come
with this file.  If it should be provided at all I think that it should
come from the "python" package, rather than any of the modules that may
or may not be installed.

What do you think?

~~ Ricardo

Re: Python conflicts.

[Federico Beffa]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Hi Guix,
>
> there are two things related to the installation of Python modules that
> I would like to see changed; but as I may not understand what side
> effects the proposed changes might have I'd like to gather some opinions
> first.
>
> 1) Nosetests
>
> Installing Python modules that have an input "python-nose" (always?)
> install "$out/bin/nosetests" and various wrappers around this script.
> This script is not very useful for a user of the module as it only runs
> the test suite.  As we're often propagating Python module inputs, the
> installation of one Python module usually results in conflicts with the
> various versions of "$out/bin/nosetests" that are to be installed into
> the profile.
>
> This makes the nosetests scripts even less useful as an arbitrary
> version will end up in the profile.  I'd like to exclude them from
> installation in all Python packages, maybe by modifying
> "python-build-system" such that the files are deleted from the output
> directory again.
>
> What I don't like about using the "python-build-system" for this is that
> "$out/bin/nosetests" is only created when "python-nose" (or
> "python2-nose") is a package input.  Is there a better way?  Can we
> prevent the creation of the "nosetests" script (and its wrappers), maybe
> with some flag to setuptools?
>
> 2) lib/python$version/site-packages/site.{py,pyc}
>
> Another file that frequently causes conflicts is "site.py" (and its
> compiled cousin).  It seems to me that "site.py" doesn't contain any
> module-specific information and is probably the same for all modules.  I
> would like to change "python-build-system" such that Python modules do
> not install this file at all.
>
> The only problem I see is that the "python" package itself does not come
> with this file.  If it should be provided at all I think that it should
> come from the "python" package, rather than any of the modules that may
> or may not be installed.

'site.py[c]' is installed and used by 'setuptools' based
programs/libraries. The purpose of the file is to add sub-directories to
PYTHONPATH. If you remove the file, libraries configured with setuptools
will not work anymore, unless you do the work done by 'site.py' in
another way.

https://pythonhosted.org/setuptools/easy_install.html

Regards,
Fede

Re: Python conflicts.

[Ricardo Wurmus]

Federico Beffa <beffa@ieee.org> writes:

>> 2) lib/python$version/site-packages/site.{py,pyc}
>>
>> Another file that frequently causes conflicts is "site.py" (and its
>> compiled cousin).  It seems to me that "site.py" doesn't contain any
>> module-specific information and is probably the same for all modules.  I
>> would like to change "python-build-system" such that Python modules do
>> not install this file at all.
>>
>> The only problem I see is that the "python" package itself does not come
>> with this file.  If it should be provided at all I think that it should
>> come from the "python" package, rather than any of the modules that may
>> or may not be installed.
>
> 'site.py[c]' is installed and used by 'setuptools' based
> programs/libraries. The purpose of the file is to add sub-directories to
> PYTHONPATH. If you remove the file, libraries configured with setuptools
> will not work anymore, unless you do the work done by 'site.py' in
> another way.
>
> https://pythonhosted.org/setuptools/easy_install.html

Currently, we have *many* packages providing this file.  My goal is to
avoid the confusing and verbose conflict warnings by only providing it
once.  Is it feasible to let our "python" package install "site.py" once
and remove the file from all other packages?

Right now we only have one of these many files installed at a time
anyway, so I assume they all have the same contents.  The "python"
package creates lib/python${version}/site-packages/ with a README
already in which "site.py" is mentioned.  I suggest we let "python"
install "site.py" once and for all.

Obviously, we cannot *just* remove it and expect things to continue
working.

~~ Ricardo