[Distutils] pbr issues (was: Where should I put tests when packaging python modules?)

Erik Bray erik.m.bray at gmail.com
Wed Oct 7 17:32:07 CEST 2015


On Tue, Oct 6, 2015 at 7:46 PM, Ionel Cristian Mărieș
<contact at ionelmc.ro> wrote:
>
> On Wed, Oct 7, 2015 at 2:23 AM, Robert Collins <robertc at robertcollins.net>
> wrote:
>>
>>
>> Hangon, there's clearly a *huge* gap in understanding here.
>>
>> pbr does *not* modify *anyones* setup.py output unless its enabled.
>
>
> Unless it's >=1.7.0. You can't blame setuptools having entrypoints for pbr
> doing weird stuff to distributions by abusing said entrypoints.
>
> For reference: https://bugs.launchpad.net/pbr/+bug/1483067
>
> There's nothing special about pbr here. It's not like it's the first package
> doing dangerous stuff (distribute, suprocess.run, pdbpp). I really like
> pdbpp, but you don't put that in production.

Starting a sub-thread since issues with pbr are orthogonal to the
original disucssion.

But one point I'd like to raise about this is that when I originally
designed d2to1, on which a chunk of pbr is based, it was *explicitly*
designed to never be installed in site-packages (with the exception of
downstream packaging systems which can do what they want and are more
controlled).  This is exactly because I knew different packages might
have dependencies on different versions of d2to1 as features are
added, and that if some version is installed in site-packages it can
lead to VersionConflict issues (this is in part exacerbated by a
bug/misfeature in setuptools--I fixed that bug a while ago but the fix
had to be rolled back due to a regression [1]).

So TL;DR unless you know what you're doing, d2to1 should *never* be
"installed"--it was only meant to be used with setup_requires, where
the appropriate d2to1 used in building/installing a package is only
temporarily enabled on sys.path via a temporary egg install.  If some
project is making it a *runtime* requirement that's a mistake.

I don't know what features pbr has grown that might make someone want
it to be a runtime dependency (the only entry-points I noticed were
for adding egg-info writers but that should only be needed at
build-time too...), but maybe something like that should be split off
as a separate module or something...

Best,
Erik


[1] https://bitbucket.org/tarek/distribute/pull-requests/20/fixes-and-adds-a-regression-test-for-323/diff


More information about the Distutils-SIG mailing list