Open eeaston opened 10 years ago
Ah, sorry about that.
I'd prefer 'a'. We have some internal code that's pinned at six==1.3.0, and some code that's pinned at six==1.4.1. It'd make my life much easier if we include a copy of six.
Otherwise, if pkglib depends on (say) six>=1.5, it would be impossible to use pkglib with packages that depend on older versions of six. That would be a shame.
Coolio, I'll move it into pkglib_util. Commit-o-doom incoming
Interestingly, pip also includes a copy of the libraries it depends on: https://github.com/pypa/pip/tree/develop/pip/_vendor
Gosh. And I thought we were being semi-bad with just the one - they have loads in there! Good spot.
My reason for creating pkglib_util was to create a non-pkglib-enabled place to put common code that's used in both pkglib and pkglib_testing. This is so pkglib_testing can be installed as a standalone package without pkglib, something some users have mentioned is desirable. The recent import of six into pkglib has reintroduced that dependency.
We can fix this by either a) move pkglib.six into pkglib_util.six, or b) re-declare six as an install dependency of pkglib_testing.
I'm re-organising pkglib_testing at the moment and going down the 'b' route at the moment, but can easily change. Whaddaya reckon?