GNU bug report logs - #27637
[PATCH] gnu: Add python-conda

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Frederick Muriithi <fredmanglis <at> gmail.com>
Cc: 27637 <at> debbugs.gnu.org
Subject: [bug#27637] [PATCH 2/2] gnu: Add conda
Date: Tue, 18 Jul 2017 01:04:48 +0200

[Message part 1 (text/plain, inline)]

Frederick Muriithi <fredmanglis <at> gmail.com> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.