Precedence: list
MIME-Version: 1.0
References: <a58597d021c9b6da1284fa0ce62235f5@server-speed.net>
 <20160603121228.5d26f586@ncopa-desktop.alpinelinux.org> <20160603141443.GB4441@eucalyptus>
In-Reply-To: <20160603141443.GB4441@eucalyptus>
From: Christian Kampka <christian@kampka.net>
Date: Fri, 03 Jun 2016 16:10:48 +0000
Message-ID: <CADq4isRzkZTMjBZuVs3s_wp+5aXF+xyf3uQvqr98+ZEh58pS9g@mail.gmail.com>
Subject: Re: [alpine-devel] Python 3 in Alpine 3.5
To: alpine-devel@lists.alpinelinux.org
Content-Type: multipart/alternative; boundary=001a114b3088d59887053461f7be

--001a114b3088d59887053461f7be
Content-Type: text/plain; charset=UTF-8

Hi,

Jiri Horner <laeqten@gmail.com> schrieb am Fr., 3. Juni 2016 um 16:14 Uhr:

> 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
> simple
> 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
> upgraded with
> system packages. Also packaged applications could declare dependencies on
> things
> in PyPI easily.
>

I am very much against this.
apk should only offer packages for which we can
a) verified content, pypi packages are not even signed, installing them
does warrent special security considerations since installing python
packages from pypi usually means running setup.py, in a system-wide
installation probably as root.

b) dependency management will be difficult, as several python packages have
non-python dependencies. Often these need to invoke a compiler to build
correctly.

c) apk should only install things for which we can guarantee (to a degree)
that they are functional on alpine, which is pretty much impossible for
pypi packages, especially if b) applies.

Natanael Copa <ncopa@alpinelinux.org> schrieb am Fr., 3. Juni 2016 um
12:12 Uhr:

> 1. clean up. (figure out what we can remove and remove it)
> 2. rename py-* to py2-*
> 3. add py3-*
>

While we are at it, we should probably check which of the remaining
packages need to remain in main and which ones can be moved to community.

Cheers,
Christian

--001a114b3088d59887053461f7be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Jir=
i Horner &lt;<a href=3D"mailto:laeqten@gmail.com">laeqten@gmail.com</a>&gt;=
 schrieb am Fr., 3. Juni 2016 um 16:14=C2=A0Uhr:</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
Have you considered integrating pip with apk? Like `apk add py-foo` would<b=
r>
invoke pip to install `foo` for you and manage upgrades too. I was using si=
mple<br>
script that did something similar, so I don&#39;t need to switch between ap=
k and<br>
pip and it was quite comfortable.<br>
<br>
This way it&#39;ll be only needed to maintain packages that need patches an=
d still<br>
python packages would remain fist-class citizens and they would be upgraded=
 with<br>
system packages. Also packaged applications could declare dependencies on t=
hings<br>
in PyPI easily.<br></blockquote><div><br></div><div>I am very much against =
this.</div><div>apk should only offer packages for which we can</div><div>a=
) verified content, pypi packages are not even signed, installing them does=
 warrent special security considerations since installing python packages f=
rom pypi usually means running setup.py, in a system-wide installation prob=
ably as root.</div><div><br></div><div>b) dependency management will be dif=
ficult, as several python packages have non-python dependencies. Often thes=
e need to invoke a compiler to build correctly.</div><div><br></div><div>c)=
 apk should only install things for which we can guarantee (to a degree) th=
at they are functional on alpine, which is pretty much impossible for pypi =
packages, especially if b) applies.</div><div><br></div><div><div dir=3D"lt=
r">Natanael Copa &lt;<a href=3D"mailto:ncopa@alpinelinux.org">ncopa@alpinel=
inux.org</a>&gt; schrieb am Fr., 3. Juni 2016 um 12:12=C2=A0Uhr:</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin=
g-left:1ex">1. clean up. (figure out what we can remove and remove it)<br>2=
. rename py-* to py2-*<br>3. add py3-*<br></blockquote><div><br></div><div>=
While we are at it, we should probably check which of the remaining package=
s need to remain in main and which ones can be moved to community.</div><di=
v><br></div><div>Cheers,</div><div>Christian =C2=A0</div></div><div><br></d=
iv><div><br></div></div></div>

--001a114b3088d59887053461f7be--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---