Hello,
Regarding fork versioning, I found this thread:
https://mail.python.org/archives/list/distutils-sig@python.org/thread/XAAN4XMQ346TYIYG4BEM6AGDUXNQHMVX/#XAAN4XMQ346TYIYG4BEM6AGDUXNQHMVX
Now, this is relating to forks that incorporate small changes, like bug fixes,
and that are meant to be
Related question – isn't auditwheel being runned against all linux
wheels before uploading fixed manylinux* wheels to pypi anyway? If
yes, probably there's a need to use another container for musl
systems, though this has to be investigated.
On Wed, Feb 27, 2019 at 7:20 PM Alexander Revin wrote:
My proposal is the following:
1) Put runtime detection function in pip, so it should decide which
platform tag to fetch from pypi;
2) Regarding auditwheel – I think it's a good point to try to mainline
Alpine's patches, so musl-compiled Python can check for libraries.
Chances are it will fix
On Fri, Mar 1, 2019, at 9:59 AM, Sofia Nunes wrote:
> So, let’s assume I fork a package which is on version 2.1. and change its
> name.
> Would my distribution version be 1.0 or 2.2/3.0? Or none of the options?
From a technical perspective, I don't think it matters: if your fork has a new
name,
I kind of feel that "third party tool can/will use this feature" is
orthogonal to "how the interpreter behaves out of the box" - unless I
misunderstand and you are suggesting python grow support for launching
entrypoints from the python executable.
> -Original Message-
> From:
Hello,
Regarding fork versioning, I found this thread:
https://mail.python.org/archives/list/distutils-sig@python.org/thread/XAAN4XMQ346TYIYG4BEM6AGDUXNQHMVX/#XAAN4XMQ346TYIYG4BEM6AGDUXNQHMVX
Now, this is relating to forks that incorporate small changes, like bug fixes,
and that are meant to be
