On 17 Jan 2014 23:22, "Matthew Iversen" <[email protected]> wrote: > > On 17/01/14 13:52, Hannes Schmidt wrote: >> >> I read through the "Removing dependency_links" thread [1] and I beg you not follow through with the deprecation and removal of dependency_links and to rethink your approach. >> >> The mentioned thread indicates that research was done to gauge the popularity of the dependency_links in publicly hosted Python projects. That approach is fundamentally flawed: Publicly hosted projects are much more likely to also be available on PyPI than private, closed-source projects. Consequently, their dependencies are also more likely to be hosted on PyPI as well. Because of that, they are much less likely to rely on the dependency_links feature. >> >> Another misconception seem to be that dependency_links is predominantly used for installing patched or customized versions of dependencies hosted on PyPI. I'm pretty sure the predominant use case for dependency_links is with projects that are hosted privately, e.g. for an organization's internal use. I represent such an organization and removing dependency_links would impact us negatively. We host a set of internal projects and their dependencies on Bitbucket and we rely on dependency_links to install them directly from there. >> >> I understand the motivation for this change – security – but there must be smarter way to handle it. Could we fallback to dependency_links if a PyPI lookup isn't successful? Could we restrict dependency_links to links that share a prefix with the link from which the package is currently being installed? A combination of the two? >> >> [1]: https://mail.python.org/pipermail/distutils-sig/2013-October/022937.html >> >> -- >> Hannes Schmidt >> Software Application Developer >> Data Migration Engineer >> Cancer Genomics Hub >> University of California, Santa Cruz >> >> (206) 696-2316 (cell) >> [email protected] >> >> >> _______________________________________________ >> Distutils-SIG maillist - [email protected] >> https://mail.python.org/mailman/listinfo/distutils-sig > > > Are you aware that you can also provide a solid infrastructure for a "proprietary environment of packages" by hosting your own private pypi mirror? > > There are quite a few projects that enable this, such as > > https://pypi.python.org/pypi/pypiserver > > https://pypi.python.org/pypi/mypypi > > https://github.com/steiza/simplepypi > > http://djangopypi2.readthedocs.org/en/latest/ > > You can use the -i flag, or a .pypirc config file to tell pip to look at your own private index instead of the official one; or direct it to use the official pypi only after looking at your private pypi. > > You can also host a network-available folder of wheels for pip to find, or simply a http accessible folder of packages as Donald suggested.
Private PyPI mirrors and internal hosting options would be a suitable advanced topic for the PUG. I don't recall whether or not Marcus already added a placeholder for it, though. Cheers, Nick. > > -- > Matt Iversen > PGP: 0xc046e8a874522973 // 2F04 3DCC D6E6 D5AC D262 2E0B C046 E8A8 7452 2973 > > > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
