[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2749: remove the version-checking code from `__init__.py`

Tahoe-LAFS trac at tahoe-lafs.org
Tue Mar 22 04:53:57 UTC 2016


#2749: remove the version-checking code from `__init__.py`
-----------------------+---------------------------
 Reporter:  warner     |          Owner:
     Type:  defect     |         Status:  new
 Priority:  normal     |      Milestone:  undecided
Component:  packaging  |        Version:  1.10.2
 Keywords:             |  Launchpad Bug:
-----------------------+---------------------------
 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.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2749>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list