On Tue, 29 Nov 2016 19:13:19 -0500 Mike Gilbert <flop...@gentoo.org> wrote:
> On Tue, Nov 29, 2016 at 6:57 PM, Brian Dolbec <dol...@gentoo.org> > wrote: > > > > While working on the last 2 version bumps to the twisted package, I > > kept getting an error in which the *egg-info/SOURCES.txt file > > absolute paths for all the files found in that very same > > directory. They are required to be relative paths only. This > > problem currently only affects some pkgs depending on the > > setuptools pkg for install. The source of the change is that > > setuptools patches the cpython findall() with one that returns > > relative paths for anything in/below the passed in base directory. > > Everything else it returns the absolute path. > > > > Why we should apply this: > > > > Python upstream has merged the setuptools findall() code and > > will be included in the next releases of python, 2.7.13, 3.4.6, > > 3.5.4 (I think). So, there is potential for many more python pkgs > > to be affected by this that are not requiring setuptools for > > install. Without the ebb-base setting, the egg-info/* files are not > > included in SOURCES.txt. The install proceeds without error. > > > > NOTE: This first affects the python_compile_all phase, long > > before it even tries to run the tests (if enabled). > > > > > > Some history: > > > > The egg-base settings were originally added for parallel > > testing/install purposes. They are not used due to problems in > > parallelizing testing, etc.. (something along those lines, I > > don't want to search thru the logs, and mails to see what > > Michal's original words were about it.) > > > > I am working on twisted-16.5.0 and 16.6.0 releases (tests are still > > failing), but 16.6.0 has many improvements to the testing code, so > > has a lot fewer errors to fix. Once these are fixed and the eclass > > changes are merged, I will be able to add it to the tree. > > > > See attached patch. NOTE: actual commit message will be > > different/updated correctly. This was just an interim patch for > > testing and initial review. > > > > Seems ok to me. Hopefully it doesn't break something in a subtle, hard > to detect way. ;-) > I agree, but with 1600+ dev-python/*.* ebuilds, it would take one hell of a tinderbox run to check for definite breakage. Subtle runtime breakage is quite another. -- Brian Dolbec <dolsen>
