[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2764: publish a new (redirecting) `allmydata-tahoe` to PyPI

[Tahoe-LAFS]

#2764: publish a new (redirecting) `allmydata-tahoe` to PyPI
--------------------------------+------------------------------------
 Reporter:  warner              |          Owner:
     Type:  task                |         Status:  new
 Priority:  normal              |      Milestone:  soon (release n/a)
Component:  dev-infrastructure  |        Version:  1.11.0
 Keywords:                      |  Launchpad Bug:
--------------------------------+------------------------------------
 Now that `tahoe-lafs-1.11.0` is on PyPI and is pip-installable, we should
 maybe do something about the old `allmydata-tahoe-1.10.2` that's on PyPI
 (and not really pip-installable).

 I was thinking we could publish a "1.10.2.post1" sort of thing, using
 [https://pypi.python.org/pypi/pypi-alias pypi-alias], that would depend
 upon `tahoe-lafs` but is otherwise empty. Anyone who accidentally did `pip
 install allmydata-tahoe`, or who had it installed and did a `pip install
 --upgrade allmydata-tahoe`, would wind up with both, but only `tahoe-lafs`
 would provide the `tahoe` executable.

 With or without this, there will be confusion when people search for
 "tahoe" on PyPI, since they'll see both packages (in fact there's a
 completely unrelated `tahoe` package up there, described as "A Flask-based
 framework that handles the tedious things", and at least one developer
 tried to install it by mistake).

 But with this, installing `tahoe-lafs` or `allmydata-tahoe` will both get
 them a modern `tahoe` executable. Without it, picking the wrong one will
 get you weird zetuptoolz errors at best, and an older version of `tahoe`
 at worst.

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