From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXNLX-00031a-5D for guix-patches@gnu.org; Tue, 18 Jul 2017 03:55:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dXNLS-0008AE-N5 for guix-patches@gnu.org; Tue, 18 Jul 2017 03:55:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42596) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dXNLS-0008A6-Hp for guix-patches@gnu.org; Tue, 18 Jul 2017 03:55:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dXNLS-0007R5-0H for guix-patches@gnu.org; Tue, 18 Jul 2017 03:55:02 -0400 Subject: [bug#27637] [PATCH 2/2] gnu: Add conda Resent-Message-ID: MIME-Version: 1.0 In-Reply-To: References: <20170713014726.21093-1-fredmanglis@gmail.com> <20170713014726.21093-2-fredmanglis@gmail.com> <87bmok6qd6.fsf@fastmail.com> <87pocy64xb.fsf@fastmail.com> From: Frederick Muriithi Date: Tue, 18 Jul 2017 10:53:53 +0300 Message-ID: Content-Type: multipart/alternative; boundary="001a113ff0b8275117055492d18c" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Marius Bakke Cc: 27637@debbugs.gnu.org --001a113ff0b8275117055492d18c Content-Type: text/plain; charset="UTF-8" On 18 Jul 2017 2:04 a.m., "Marius Bakke" wrote: Frederick Muriithi 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. --001a113ff0b8275117055492d18c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 t= hat 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<= br> > * an executable form that can be run on the cli
>
> I defined python-conda to provide the library form, whereas conda was<= br> > 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 rem= ove
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&= #39;?
>>
>
> 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' o= nly
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. T= he previous
>> patch (from PyPi) did not have tests either, so I suppose we shoul= d use
>> this release (but we should really figure out why setup.py is brok= en).
>
> 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<= br> 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 provi= de both for completeness.

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

--001a113ff0b8275117055492d18c--