replace _auto_deps with a pkg_resources API call #2283

New Issue

zooko · 2014-08-19T18:10:37Z

zooko commented

2014-08-19 18:10:37 +00:00

In [setup.py]source:trunk/setup.py?annotate=blame&rev=7db853a777d5cecd39eeb7350ce45f4f34ff5095#L60 we use a separate file named [_auto_deps.py]source:trunk/src/allmydata/_auto_deps.py?annotate=blame&rev=7bb07fb5e28756fa13ba5190e6c39003c84d3e1e 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.

In [setup.py]source:trunk/setup.py?annotate=blame&rev=7db853a777d5cecd39eeb7350ce45f4f34ff5095#L60 we use a separate file named [_auto_deps.py]source:trunk/src/allmydata/_auto_deps.py?annotate=blame&rev=7bb07fb5e28756fa13ba5190e6c39003c84d3e1e 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.

zooko added the

labels 2014-08-19 18:10:37 +00:00

zooko added this to the undecided milestone 2014-08-19 18:10:37 +00:00

zooko commented

2014-08-19 18:11:37 +00:00

dstufft explained on IRC that you can get this information at run-time with:

     pkg_resources.get_distribution("allmydata-tahoe").requires()

dstufft explained on IRC that you can get this information at run-time with: ``` pkg_resources.get_distribution("allmydata-tahoe").requires() ```

daira commented

2014-08-21 01:52:45 +00:00

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. (The install_requires definition is about half of _auto_deps.py.)

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. (The `install_requires` definition is about half of `_auto_deps.py`.)

warner commented

2016-03-26 23:32:24 +00:00

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?).

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`?).

warner modified the milestone from undecided to 1.12.0

2016-03-26 23:32:24 +00:00

warner commented

2016-06-28 18:20:37 +00:00

moving most tickets from 1.12 to 1.13 so we can release 1.12 with magic-folders

warner modified the milestone from 1.12.0 to 1.13.0

2016-06-28 18:20:37 +00:00

warner commented

2016-09-03 02:25:59 +00:00

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.

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`.

exarkun commented

2019-08-13 23:05:21 +00:00

(https://github.com/tahoe-lafs/tahoe-lafs/pull/646)

GitHub <noreply@github.com> commented

2019-08-14 01:43:15 +00:00

In eb751ba/trunk:

Merge pull request #646 from tahoe-lafs/2283.use-pkg_resources

Use pkg_resources instead of _auto_deps.install_requires

Fixes: ticket:2283

In [eb751ba/trunk](/tahoe-lafs/trac-2024-07-25/commit/eb751baeef935f02bbdc1b1ed7ce8774d5e47be1): ``` Merge pull request #646 from tahoe-lafs/2283.use-pkg_resources Use pkg_resources instead of _auto_deps.install_requires Fixes: ticket:2283 ```

tahoe-lafs added the

fixed

label 2019-08-14 01:43:15 +00:00

tahoe-lafs closed this issue

2019-08-14 01:43:15 +00:00

Sign in to join this conversation.