Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On 7 November 2016 at 07:20, Chris Barker wrote: > So how is allowing anyone to push something to PyPi that will run arbitrary > code on a CI server, that will push arbitrary code to PyPi that will then > get run by anyone that pip installs it? PyPI currently has the

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Fri, Nov 4, 2016 at 11:29 PM, Nick Coghlan wrote: > If I understand correctly, conda-forge works on the same basic > principle - reviewing the publishers before granting them publication > access, rather than defending against arbitrarily malicious code at > build time. >

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Saturday, November 5, 2016, Wes Turner wrote: > For automated deployment / continuous deployment / "continuous delivery": > > - pip maintains a local cache > - devpi can be configured as a transparent proxy cache (in front of > pypi.org) >

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

For automated deployment / continuous deployment / "continuous delivery": - pip maintains a local cache - devpi can be configured as a transparent proxy cache (in front of pypi.org ) - GitLab CI can show a checkmark for a deploy pipeline stage On Saturday, November 5, 2016, Wes Turner

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Saturday, November 5, 2016, Nick Coghlan wrote: > On 4 November 2016 at 06:07, Nathaniel Smith > > wrote: > > I think we're drifting pretty far off topic here... IIRC the original > > discussion was about whether the travis-ci infrastructure

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On 4 November 2016 at 06:07, Nathaniel Smith wrote: > I think we're drifting pretty far off topic here... IIRC the original > discussion was about whether the travis-ci infrastructure could be suborned > to provide an sdist->wheel autobuilding service for pypi. (Answer: maybe, >

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

I don't know if it has been mentioned before, but Travis already provides a way to automatically package and upload sdists and wheels to PyPI: https://docs.travis-ci.com/user/deployment/pypi/ I've been using it myself in many projects and it has worked quite well. Granted, I haven't had to

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

I think we're drifting pretty far off topic here... IIRC the original discussion was about whether the travis-ci infrastructure could be suborned to provide an sdist->wheel autobuilding service for pypi. (Answer: maybe, though it would be pretty awkward, and no one seems to be jumping up to make

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Nov 03, 2016, at 11:08 AM, Glyph Lefkowitz wrote: >I think phrasing this in terms of "perfect" and "good enough" presents a >highly misleading framing. Examined in this fashion, of course we may >reluctantly use the "good enough" option, but don't we want the best option? What are the

[Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

> On Nov 3, 2016, at 10:17 AM, Barry Warsaw wrote: > > On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote: > >> This is also an area where I'm fine with recommending freemium >> solutions if they're the lowest barrier to entry option for new users, >> and "Use GitHub + Travis