Opened at 2014-08-19T18:10:37Z
Closed at 2019-08-14T01:43:15Z
#2283 closed enhancement (fixed)
replace _auto_deps with a pkg_resources API call
Reported by: | zooko | Owned by: | GitHub <noreply@…> |
---|---|---|---|
Priority: | normal | Milestone: | 1.13.0 |
Component: | packaging | Version: | 1.10.0 |
Keywords: | review-needed setuptools | Cc: | |
Launchpad Bug: |
Description
In setup.py we use a separate file named _auto_deps.py so that both the build system that is executing setup.py at build-time and the running Tahoe-LAFS app itself at run-time can both query what the requirements are, while respecting the DRY (Don't Repeat Yourself) principle.
Change History (7)
comment:1 Changed at 2014-08-19T18:11:37Z by zooko
comment:2 Changed at 2014-08-21T01:52:45Z by daira
That seems to work (that is, it gives a list of Requirement objects corresponding to install_requires). So it's a valid alternative approach to what we have now, but I'm not sure it actually helps all that much. We Don't Repeat Ourselves already -- this would just mean we could choose to move the definition of install_requires to setup.py, say, which wouldn't by itself reduce complexity.
comment:3 Changed at 2016-03-26T23:32:24Z by warner
- Milestone changed from undecided to 1.12.0
I like this, as I'd like to see that funky execfile in setup.py go away. I'd like to do this at the same time as #2749, and move the make-sure-we-have-what-we-think-we-need code into a separate diagnostic command (maybe tahoe --check-versions?).
comment:4 Changed at 2016-06-28T18:20:37Z by warner
- Milestone changed from 1.12.0 to 1.13.0
moving most tickets from 1.12 to 1.13 so we can release 1.12 with magic-folders
comment:5 Changed at 2016-09-03T02:25:59Z by warner
Would this really mean replacing a lot of the diagnostic "what version got installed, and does it meet our requirements?" code in __init__.py? I think *that*'s the deeper problem. I agree with Daira that _auto_deps.py isn't all that complicated (but I strongly feel that its install_requires contents should be moved into setup.py).
What if we made a module named allmydata.versioncheck? We would move all the non-install_requires stuff from _auto_deps.py into there, we'd get rid of the deprecation-suppression and fix those warnings directly (I have to imagine that most of them are resolved by now), we'd move all the check-and-compare-versions stuff from __init__.py into versioncheck too, make it a function, that gets called by tahoe --check-versions, and then part of the troubleshooting process is to run this command, maybe do it automatically when you do something early, like tahoe --version or tahoe create-client.
comment:6 Changed at 2019-08-13T23:05:21Z by exarkun
- Keywords review-needed added
comment:7 Changed at 2019-08-14T01:43:15Z by GitHub <noreply@…>
- Owner set to GitHub <noreply@…>
- Resolution set to fixed
- Status changed from new to closed
In eb751ba/trunk:
dstufft explained on IRC that you can get this information at run-time with: