guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#27637] [PATCH 2/2] gnu: Add conda


From: Marius Bakke
Subject: [bug#27637] [PATCH 2/2] gnu: Add conda
Date: Tue, 18 Jul 2017 01:04:48 +0200
User-agent: Notmuch/0.24.2 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu)

Frederick Muriithi <address@hidden> writes:

>> The previous patch also creates "$out/bin/conda". Does that executable
>> not work? Why do we need both packages?
>>
>
> Conda has two forms:
>
> * a python library form, that can be included in python programs, and
> * an executable form that can be run on the cli
>
> I defined python-conda to provide the library form, whereas conda was
> to provide the executable form.

My question was more whether it made sense to provide two different
packages, if they both have the same files. Does the `conda` executable
from 'python-conda' work differently? Maybe we should rename or remove
it to avoid conflicts?

>> There are a few phases that messes with the tests, yet they are
>> disabled. Why?
>
> My bad. I will reactivate them. Must have left that in by mistake. My 
> apologies.

Great, thanks!

>> Wooow. What happens with the default 'python setup.py install'?
>>
>
> The default setup.py builds the python library form, whereas the
> utils/setup-testing.py builds the executable version

Ahh okay. Having read both scripts it looks like 'setup.py' only
installs "conda.cli.pip_warning:main" instead of the real thing. Sorry
for the confusion!

>> Unless there exists a good reason to both have a "conda" package and a
>> 'python-conda', I think we should consolidate these two. The previous
>> patch (from PyPi) did not have tests either, so I suppose we should use
>> this release (but we should really figure out why setup.py is broken).
>
> I don't think setup.py is broken, I think the conda team built it that
> way, so that one is explicit on what they want to do, at least that is
> what I could gather from my reading on it. I will redefine the
> packages to make it cleaner, and simply use the release/url that has
> the tests to define both.

Sounds good. I still think it's worth investigating if this "official"
(quotes since it's still explicitly unsupported) build method also can
be used as a library so we can avoid maintaining three variants of
nearly the same package. Let us know what you find :-)

Thanks!

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]