[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!
signature.asc
Description: PGP signature
[bug#27637] [PATCH 1/5] gnu: Add python-pytz, Muriithi Frederick Muriuki, 2017/07/18