Re: [Distutils] Wheel files for PPC64le
Hi there, First of all, thanks for checking out the information about Docker images, Nick! Since Leonardo's last email got some formatting issues, I'm fixing it (mostly manually) and sending it here again. Kind regards, Bruno Rosa -- > Having manylinuxN consistently align with CentOS(N+4) seems reasonable to me > for simplicity's sake, but there should be a discussion in the PEP around how > that aligns with ppc64le support on other LTS distros (mainly Debian and > Ubuntu). > Given the relative dates involved, I'd expect manylinux-style binaries > compiled on CentOS 7 to also work on Ubuntu 14.04, 16.04 and Debian 8, but > the PEP should explicitly confirm that the nominated symbol versions above > are available on all of those distros. Ok, I can add it to the PEP, but regarding the supported distros, the older than CentOS 7 may not be compatible, based on the backward compatibility rules, that does not guarantee compatibility with older versions, only with newer. I sent a message about it here https://mail.python.org/pipermail/wheel-builders/2017-March/000265.html. > I don't think is quite that simple, as installers need to be able to figure > out: > - on manylinux3 compatible platforms, prefer manylinux3 to manylinux1 > - on manylinux3 *in*compatible platforms, only consider manylinux1 > And that means asking the question: when combined with the option of the > distro-provided `_manylinux` module, is "have_compatible_glibc(2, 5) and not > have_compatible_glibc(2, 17)" an adequate check for the latter case? (My > inclination is to say "yes", but it would be helpful to have some more > concrete data on glibc versions in different distros of interest) Well, I didn’t realize that proposing a new tag would require an additional check about the tags, which will be a requirement for the manylinux2 as well, when the CentOS 5 be replaced by CentOS 6 for x86_64/i686. I need to check where and how the method “is_manylinux1_compatible” is used to think how it would be done. I will check that and propose how to do it. > Beyond that, I think the main open question would be: do we go ahead and > define the full `manylinux3` specification now? CentOS 7+, Ubuntu 14.04+, > Debian 8+ compatibility still covers a *lot* of distros and deployments, and > doing so means folks can bring the latest versions of gcc to bear on their > code, rather than being limited to the last version that was made available > for RHEL/CentOS 5 (gcc 4.8). Actually the idea was make it available for PPC64le, just as it is available to x86_64/i686 nowadays, like porting it. I didn’t think about the definition of all requirements for the manylinux3 for all architectures, as it can change until x86_64/i686 get to the manylinux3. Being limited to an old version, as CentOS 5 (gcc 4.8) is a requirement from PEP 513, which guarantees the backward compatibility, right? I do not want to change it, this proposal is just to create a tag for PPC64le, until both architectures get to the same base distro version. As I said above, I have already sent a message about basing it on CentOS 7, which does not guarantee the compatibility with older distros (example: Ubuntu 14.04). Is there any thinking about base on a newer distro and make the wheel files compatible with distros older than it? Sorry if I’m missing something here. I’m coping the Bruno Rosa, which will be involved with this PEP as well. Cheers, Leonardo Bianconi. -- ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Source of confusion
> On Mar 30, 2017, at 4:07 AM, Paul Moore wrote: > > On 30 March 2017 at 08:36, Thomas Güttler > wrote: >> Why two repo providers, why two mailing lists. This confuses new comers. >> >> I think this is precise feedback. > > Because there is more than one project, and because the topics of > discussion are different on the two. > Paul > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig To expand upon this a little more, PyPA is not really a formal organization where we dictate top down about how projects must operate. About the only requirements we have are that your project relates in some way to Python’s packaging toolchain and that you accept being bound by our CoC. Beyond that projects under the PyPA banner are operated independently of each other with their own policies and procedures and such. It provides some loose organization and a “brand” but that’s really about all, so while most projects have opted to use GitHub, not all of them have (and that’s ok!). The two mailing lists are *largely* historical really, there was a time when distutils-sig (and before that even, catalog-sig) was not a particularly pleasant place to discuss things at and as such it made sense to try and sequester yourself away from it for some kinds of discussions. This has gotten a lot better in recent years and *most* mailing list like discussion tends to happen here on distutils-sig. Couple that with the fact that the individual projects tend to use their issue trackers to hold discussions that are specific to their particular project and we could probably consolidate, but I also don’t think it’s a big deal either. — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Which commercial vendor?
On 30 March 2017 at 18:53, Thomas Güttler wrote: > Am 29.03.2017 um 10:27 schrieb Nick Coghlan: >> The Python ecosystem *does* include commercial vendors that offer to >> make opinionated technical decisions on behalf of their customers, as >> well as providing a single point of contact for support questions and >> feature requests, but beyond that, offering an overwhelming array of >> confusing choices is pretty much the way open source *works*. > > My frustration has reached a limit. Yes, I am willing to pay money. > > Which vendor do you suggest to give me a reliable package management? For cross-platform use cases, the best known options are ActiveState, Enthought, and Continuum Analytics (with the latter two focusing primarily on data analysis tasks). Another option if you're looking to bundle your own applications is PyRun, from eGenix: http://www.egenix.com/products/python/PyRun/ Finally, if you're solely interested in Linux, then Python runtimes are generally covered by commercial Linux support agreements. However, exactly which of the available commercial support options will be the best fit for your needs will depend on what you're aiming to do, and how it aligns with their product offerings. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Which commercial vendor?
Am 29.03.2017 um 10:27 schrieb Nick Coghlan: On 29 March 2017 at 17:51, Paul Moore wrote: On 29 March 2017 at 06:29, Thomas Güttler wrote: I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction. To do what? As far as I can tell, to get a customer experience instead of a prospective co-contributor one. I'm sorry Thomas, as long as you continue looking for a coherent customer experience from a collaborative collection of volunteer-run community projects, you're going to continually be confused and disappointed. The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*. My frustration has reached a limit. Yes, I am willing to pay money. Which vendor do you suggest to give me a reliable package management? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Source of confusion
On 30 March 2017 at 08:36, Thomas Güttler wrote: > Why two repo providers, why two mailing lists. This confuses new comers. > > I think this is precise feedback. Because there is more than one project, and because the topics of discussion are different on the two. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Source of confusion
Am 29.03.2017 um 11:47 schrieb Paul Moore:
On 29 March 2017 at 10:31, Thomas Güttler wrote:
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler
wrote:
I am stupid and missing a guiding hand which gives me simple straight
forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the
upstream.
I think Nick's point probably covers this discussion, but you haven't
said what you want docs *for*. pip? setuptools? wheel?something else?
If you are wearing new comer glasses, you don't know exactly what you are
looking for.
If you would know that, then you would be an expert. And then you don't need a
guiding hand.
They are in various places, which you can hunt out via pypi or google.
It's not hard to do, but certainly it's true that it's harder to find
things than you'd want if you were paying for a well-documented
service. But given that you're not paying anything, and no-one working
on Python packaging has any obligation to meet your expectations,
you'll need to either lower the level of your expectations, pay
someone to provide what you're looking for, or offer your own time and
energy to address the issues you find. Simply making vague complaints
on this list isn't particularly productive.
The complaint is vague? Here is it more precise:
Quoting https://www.pypa.io/en/latest/
{{{
They host projects on github and bitbucket, and discuss issues on the pypa-dev
and distutils-sig mailing lists.
}}}
Why two repo providers, why two mailing lists. This confuses new comers.
I think this is precise feedback.
Sorry if that's not the response you were hoping for, and in
particular if you have a pressing need for support that we're not
providing, I do understand how that can be a problem for you, but as
Nick says, this is the reality of relying on software that's provided
to you free of charge.
Yes, Nich is right.
Regards,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Source of confusion
Am 29.03.2017 um 10:27 schrieb Nick Coghlan: On 29 March 2017 at 17:51, Paul Moore wrote: On 29 March 2017 at 06:29, Thomas Güttler wrote: I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction. To do what? As far as I can tell, to get a customer experience instead of a prospective co-contributor one. You are right I'm sorry Thomas, as long as you continue looking for a coherent customer experience from a collaborative collection of volunteer-run community projects, you're going to continually be confused and disappointed. You are right The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*. You are right. Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
