Precedence: list
MIME-Version: 1.0
In-Reply-To: <20160603141443.GB4441@eucalyptus>
References: <a58597d021c9b6da1284fa0ce62235f5@server-speed.net>
 <20160603121228.5d26f586@ncopa-desktop.alpinelinux.org> <20160603141443.GB4441@eucalyptus>
From: Sander Maijers <s.n.maijers@gmail.com>
Date: Fri, 3 Jun 2016 17:20:53 +0200
Message-ID: <CAGRPH5VJyh+41ZfMOJA5pFcNWp5r4dy3uH6SbG4L5jh2CSVVuA@mail.gmail.com>
Subject: Re: [alpine-devel] Python 3 in Alpine 3.5
To: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I use a lot of Python including Aports, and would not mind if they
were all removed. It would be good though if documentation is provided
how to get up and running installing python packages. E.g.
ca-certificates must be installed first for pip to work properly with
PyPI.

You can measure popularity by checking the number of downloads of
Python Aports. This will give a more direct measure than general
popularity, namely the likelihood that Alpine Linux users will be
dissatisfied once those Aports are no longer available. Please check
who is currently maintaining py3 Aports and query them, as they may be
more offended if Aports are removed without a lot of consultation than
users in general.

I also think Jiri's idea is interesting. For this apk extension, do
consider defaulting to the pip options:
--disable-pip-version-check
--isolated
--no-cache-dir

Best,
Sander

On Fri, Jun 3, 2016 at 4:14 PM, Jiri Horner <laeqten@gmail.com> wrote:
>
> On Fri, Jun 03, 2016 at 12:12:28PM +0200, Natanael Copa wrote:
>>
>> On Thu, 02 Jun 2016 12:29:17 +0200
>> Bart*omiej Piotrowski <b@bpiotrowski.pl> wrote:
>>
>>> Hi all,
>>>
>>> we already discussed Python 3 support at least 3 times. As we recently
>>> released new stable series, edge is again open for all happy breakage
>>> so let's make use of it.
>>>
>>> Before I start though, I ran a simple grep on aports and it turns out
>>> there are 575 packages providing various Python libraries. I think this
>>> is much beyond our resources to keep all of them up to date, including
>>> possible security fixes.  Following recent Ruby example, I would love t=
o
>>> limit this set to only very popular libraries (Flask, Requests, etc) an=
d
>>> these that require to be patched to successfully build (numpy). I can
>>> also
>>> see an exception for all compiled libraries. The question is how to
>>> measure
>>> popularity; if that becomes a concern, I would rather drop all pure
>>> Python
>>> modules instead.
>>
>>
>> The difference between python and ruby module packages is that python
>> are much easier to package an maintain. Upgrading python packages is
>> fast too, so I actually don't mind keeping then.
>>
>> Ruby packages on the other hand was almost impossible to maintain,
>> which is why they got removed.
>>
>
> Have you considered integrating pip with apk? Like `apk add py-foo` would=
 invoke pip to install `foo` for you and manage upgrades too. I was using s=
imple script that did something similar, so I don't need to switch between =
apk and pip and it was quite comfortable.
>
> This way it'll be only needed to maintain packages that need patches and =
still
> python packages would remain fist-class citizens and they would be upgrad=
ed with system packages. Also packaged applications could declare dependenc=
ies on things in PyPI easily.
>
> Cheers,
> Jiri
>
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---