all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: Python conflicts.
@ 2015-06-30  7:01 Federico Beffa
  2015-06-30  8:04 ` Ricardo Wurmus
  0 siblings, 1 reply; 3+ messages in thread
From: Federico Beffa @ 2015-06-30  7:01 UTC (permalink / raw)
  To: ricardo.wurmus; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Python conflicts.
@ 2015-06-29 12:31 Ricardo Wurmus
  0 siblings, 0 replies; 3+ messages in thread
From: Ricardo Wurmus @ 2015-06-29 12:31 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-06-30  8:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-30  7:01 Python conflicts Federico Beffa
2015-06-30  8:04 ` Ricardo Wurmus
  -- strict thread matches above, loose matches on Subject: below --
2015-06-29 12:31 Ricardo Wurmus

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.