On 10.02.2016 11:08, Paul Moore wrote: > On 10 February 2016 at 09:34, M.-A. Lemburg <m...@egenix.com> wrote: >> I'm not sure I'm parsing your comment correctly, but if you are >> suggesting that PyPI should no longer allow supporting >> non-open-source packages, this is definitely not going to >> happen. > > Not at all.
That's good to know :-) > Although as far as I know the number of closed-source packages > on PyPI is vanishingly small... > > My concern is that we seem to be opening up the option of using > non-setuptools build systems without having a good solution for people > *wishing* to upload sources. It's more a matter of timing - if we > allow people to use (say) flit for their builds then presumably a > proportion of people will, because it's easier to use than setuptools, > *for builds*. But those people will then find that distributing their > sources isn't something that flit covers, so they'll make up their own > approach (if it were me, I'd probably just point people at the > project's github account). > > Once people get set up with a workflow that goes like this (build > wheels and point people to github for source) it'll be harder to > encourage them later to switch *back* to a process of uploading > sources to PyPI. > > And that I do think is bad - that we end up pushing people who would > otherwise happily use PyPI for source and binary hosting, to end up > with a solution where they host binaries only on PyPI and make the > source available via another (non-standardised) means. That's a fair argument indeed. > In no way though am I proposing that we stop people making deliberate > choices on how they distribute their packages. Just that we make > hosting both source and binaries on PyPI the "no friction" easy option > for (the majority of?) people who don't really mind, and just want to > make their work publicly available. Well, you know, there's an important difference between making work publicly available and giving away the source code :-) But I get your point and do support it: It should be possible for package authors to use different build tools than distutils. IMO, that's easy to achieve, though, with the existing de-facto standard interface we already have: the setup.py command line API. We'd just need to publish the minimal set of commands and options, installer will want to see implemented in order to initiate the builds. > PS This has gone a long way off the topic of the build interface > proposal, so I'm glad it's been spun off into its own thread. I'm now > of the view that this relates at best peripherally to the build > interface proposal, which I'll comment on in the other thread. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 10 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ 2016-01-19: Released eGenix pyOpenSSL 0.13.13 ... http://egenix.com/go86 ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
