On 11/09/16 14:43, Ludovic Courtès wrote:
>> The main reason why I didn't just improve the importer is that I was
>> looking for a way to collaborate around getting multiple versions of
>> python packages building and working, and as far as I am aware, Guix
>> only contains multiple versions of the same piece of software in some
>> special cases?
> 
> That’s right: we keep multiple versions only when people or packages
> expect to be able to choose among them (e.g., the various GnuPG series,
> GCC, Python 2.x vs. 3.x).  That’s usually a case-by-case decision,
> because every additional version that is kept entails additional
> maintenance work.
> 
> The same would apply here: we could have multiple versions of some
> packages, and only one version of the majority of them.
> 
> What do you think of this approach in the Python context?

I've been quite lucky, as I have managed to stay away from using pip and
other Python specific packaging things (by using Debian packages), but,
lots of people do use these tools.

In the future, I would love to be able to use Guix when writing Python,
and to encourage others to do similarly. Ignoring myself and
generalising, most people who use Python use pip and pip though using
pypi.python.org allows installing one of many available versions of a
particular package. Therefore, I would think that most people who
consider using Guix for a similar use case in which they use pip, would
expect to be able to choose among multiple versions of every package.

I don't think adding every release of every bit of free software on
pypi.python.org in to Guix is feasible, or something that I would want
to propose doing, but I still would really like something that gives
Guix equal (or greater) utility with respect to Python packages.

Which is why I started thinking, and then developing a way of
automatically importing releases from pypi.python.org in to a Guix
package repository that depends on Guix.

All of this is still very uncertain in my mind, in particular, I see
Guix as a viable alternative to lots of domain specific package
managers, which I would really like to avoid when writing software (e.g.
pip, npm gem) but I'm not certain that being a viable alternative to
these tools is within the project scope?

The other main uncertainty in my mind is whether the approach I have
been trying is the best one? I'm getting more confident that this is
possible, although there are still technical problems (for example,
adding new versions, without breaking existing versions of other
packages) that I haven't solved yet.