id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
2749	remove the version-checking code from `__init__.py`	warner	GitHub <noreply@…>	"I think it's time we removed the (large!) chunk of code in `src/allmydata/__init__.py` that measures and checks versions of our dependencies at startup.

I'd like to see a small subset of this code move into a utility function (maybe `src/allmydata/version_checks.py`): just enough to pull version strings for our known dependencies. This would support the extended form of `tahoe --version`. I think this code should *not* know what the setup.py `install_requires=` is, nor should it make any attempt to pass judgement upon whether the versions it finds are good enough.

Then I'd like to delete everything else from `__init__.py` except for the Versioneer setup clause (#2748).

`pip` now has responsibility for ensuring that the target virtualenv has the right code at install time, and (I think) the entrypoint script has that responsibility at runtime. The code in `__init__.py` duplicates this, plus it frequently misfires, emitting a traceback-like warning that many users mistake for a fatal exception.

This would let us move the list of `install_requires=` into `setup.py` where it belongs, rather than the current arrangement where it lives in src/ but gets `execfile()`ed by `setup.py` (which is causing problems with py3-based tox runs, #2747).

One counter-argument I can think of: you `pip install --editable .` from a git checkout into a virtualenv, work for a while and everything is fine, then you do an update and get a `setup.py` that bumps the dependency on something. If you don't update your virtualenv every once in a while (`pip list -o`, `pip install -U` on anything it says is out-of-date), then eventually Tahoe will want more than what you've got.

I think the entrypoint script is supposed to do this checking, but you'd need to at least re-run `setup.py egg_info` to update the list of dependencies that it looks at. Having something at runtime would guard against this, and the shared `_auto_deps.py` is the cleanest way to accomplish that.

But I still think our `__init__.py` is too big, and I don't like having all that code run at import, and I don't think the git-update case is worth protecting against.
"	defect	closed	normal	undecided	packaging	1.10.2	fixed