<br><br>On Thursday, December 8, 2016, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Putting the conclusion first, I do see value in better publicising<br>
"Recommended libraries" based on some automated criteria like:<br>
<br>
- recommended in the standard library documentation<br>
- available via 1 or more cross-platform commercial Python redistributors<br>
- available via 1 or more Linux distro vendors<br>
- available via 1 or more web service development platforms<br>
<br></blockquote><div><br></div><div>So these would be attributes tracked by a project maintainer and verified by the known-good-set maintainer? Or?</div><div><br></div><div>(Again, here I reach for JSONLD. "count n" is only so useful; *which* {[re]distros, platforms, heartfelt testimonials from incredible experts} URLs )</div><div><br></div><div>- test coverage </div><div>- seclist contact info AND procedures</div><div>- more than one super admin maintainer</div><div>- what other criteria should/could/can we use to vet open source libraries?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That would be a potentially valuable service for folks new to the<br>
world of open source that are feeling somewhat overwhelmed by the<br>
sheer number of alternatives now available to them.<br>
<br>
However, I also think that would better fit in with the aims of an<br>
open source component tracking community like <a href="http://libraries.io" target="_blank">libraries.io</a> than it<br>
does a publisher-centric community like distutils-sig.</blockquote><div><br></div><div>IDK if libraries are really in scope for stackshare. The feature upcoming/down voting is pretty cool.</div><div><br></div><div><a href="https://stackshare.io/python">https://stackshare.io/python</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The further comments below are just a bit more background on why I<br>
feel the integration testing aspect of the suggestion isn't likely to<br>
be particularly beneficial :)</blockquote><div><br></div><div>A catch-all for testing bits from application-specific integration test suites could be useful (and would likely require at least docker-compose, dox, kompose for working with actual data stores)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 9 December 2016 at 01:10, Barry Warsaw <<a href="javascript:;" onclick="_e(event, 'cvml', 'barry@python.org')">barry@python.org</a>> wrote:<br>
> Still, there may be value in inter-Python package compatibility tests, but<br>
> it'll take serious engineering effort (i.e. $ and time), ongoing maintenance,<br>
> ongoing effort to fix problems, and tooling to gate installability of failing<br>
> packages (with overrides for downstreams which don't care or already expend<br>
> such effort).<br>
<br>
I think this is really the main issue, as both desktop and server<br>
environments are moving towards the integrated platform + isolated<br>
applications approach popularised by mobile devices.<br>
<br>
That means we end up with two very different variants of automated<br>
integration testing:<br>
<br>
- the application focused kind offered by the likes of <a href="http://requires.io" target="_blank">requires.io</a> and<br>
<a href="http://pyup.io" target="_blank">pyup.io</a> (i.e. monitor for dependency updates, submit PRs to trigger<br>
app level CI)<br>
- the platform focused kind employed by distro vendors (testing all<br>
the platform components work together, including the app isolation<br>
features)<br>
<br>
The first kind makes sense if you're building something that runs *on*<br>
platforms (Docker containers, Snappy or FlatPak apps, web services,<br>
mobile apps, etc).<br>
<br>
The second kind inevitably ends up intertwined with the component<br>
review and release engineering systems of the particular platform, so<br>
it becomes really hard to collaborate cross-platform outside the<br>
context of specific projects like OpenStack that provide clear<br>
definitions for "What components do we collectively depend on that we<br>
need to test together?" and "What does 'working' mean in the context<br>
of this project?".<br>
<br>
Accordingly, for an initiative like this to be successful, it would<br>
need to put some thought up front into the questions of:<br>
<br>
1. Who are the intended beneficiaries of the proposal?<br>
2. What problem does it address that will prompt them to contribute<br>
time and/or money to solving it?<br>
3. What do we expect people to be able to *stop doing* if the project<br>
proves successful?<br>
<br>
For platform providers, a generic "stdlib++" project wouldn't really<br>
reduce the amount of integration testing we'd need to do ourselves (we<br>
already don't test arbitrary combinations of dependencies, just the<br>
ones we provide at any given point in time).<br>
<br>
For application and service developers, the approach of pinning<br>
dependencies to specific versions and treating updates like any other<br>
source code change already works well in most cases.<br>
<br>
That leaves library and framework developers, who currently tend to<br>
adopt the policy of "for each version of Python that we support, we<br>
test against the latest versions of our dependencies that were<br>
available at the time we ran the test", leaving testing against older<br>
versions to platform providers. If there's a key related framework<br>
that also provides LTS versions (e.g. Django), then some folks may add<br>
that to their test matrix as well.<br>
<br>
In that context, "Only breaks backwards compatibility for compelling<br>
reasons" becomes a useful long term survival trait for libraries and<br>
frameworks, as gratuitous breakages are likely to lead to people<br>
migrating away from particularly unreliable dependencies.</blockquote><div><br></div><div>Sometimes, when there are no active maintainers for a feature, it makes sense to deprecate and/or split that functionality / untested cruft out to a different package.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="javascript:;" onclick="_e(event, 'cvml', 'ncoghlan@gmail.com')">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="javascript:;" onclick="_e(event, 'cvml', 'Distutils-SIG@python.org')">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
</blockquote>