On 18 Jul 2017 2:04 a.m., "Marius Bakke" <mbakke@fastmail.com> wrote:

Frederick Muriithi <fredmanglis@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!


Well, we can drop python-conda (the library form) if necessary. My main
focus is conda as an application/executable, but thought to provide both
for completeness.

The patches will be coming in soon, fixing most of the Marius noted.