allmydataectomy: rename "allmydata" package to "tahoe_lafs" or "tahoelafs"

[warner]

Now that allmydata.com has been dead for like 5 years, it's probably time to remove "allmydata" from the package name. This means:

• replace all imports with relative imports (reducing the code impact of a rename), which is possible because we now require a python version that provides relative imports
• decide on "tahoe_lafs" or "tahoelafs" or "tahoe" or "TahoeLAFS"
• rename the src/allmydata/ directory to match
• update the setup.py metadata to match
• change the name we use for git tags, currently like allmydata-tahoe-1.10, maybe to just "1.10" or "v1.10"
• update the PyPI package, debian/ubuntu packages, etc, if they're using the old allmydata-tahoe name

[daira]

So let me play devil's advocate: why is this a good use of our time?

[warner]

Good question! It's not. Just a cleanup thing. It might be confusing to users/developers, "hey, I thought this project was called tahoe, what's this allmydata thing?", but to be honest I've never heard an actual user/developer complain or even mention that.

Moving to relative imports is probably a worthwhile cleanup thing even if we don't change the top-level name. But that's still relatively low-value.

From a reduced typing point-of-view, I kind of like the idea of tags named "1.10" instead of "allmydata-tahoe-1.10".

[zooko]

It might help reduce confusion about whether there is a commercial, proprietary interest in Tahoe-LAFS. This is something that a few contributors expressed concern about recently, e.g. #1938. Of course removing the legacy name is not sufficient to explain that stuff -- we still need explicit documentation of the governance and licensing facts -- but it might help.

Also, I don't know about you, but I regard legacy names as "cruft" or "dirt" that adds a tiny bit of cognitive load to the new reader.

[daira]

#1159 is a blocker for this ticket because the tac files in existing node directories import the 'allmydata' module, and so renaming the module would break compatibility, until we stop executing tac files.

[ClashTheBunny]

The ​PEP on naming modules and packages says to not use "-" or cases, so I would then chose "tahoe". As people have mentioned previously, tahoe is an implementation of a LAFS, it's not the only one that will ever exist. It's ​not used for many things in computing, it's less than 8 characters and is lowercase (for legacy file systems), and it's the name of this implementation of a LAFS. I don't think many people will be running tahoe off of a FAT filesystem without long filenames, but since that's patented, I can imagine it happening. Mac OS X HFS+ is case insensitive by default, I believe.

[nejucomo]

There's a subset of this issue about "distribution names" that is somewhat separate from python module namespaces. Observe:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.7 (squeeze)
Release:        6.0.7
Codename:       squeeze

$ apt-cache search allmydata

$ apt-cache search lafs
tahoe-lafs - Secure distributed filesystem

$ apt-cache search tahoe
tahoe-lafs - Secure distributed filesystem

$ pip search tahoe
allmydata-tahoe           - secure, decentralized, fault-tolerant filesystem
tahoe                     - A Flask-based framework that handles the tedious things
pytahoe                   - Python module for working with the Tahoe-LAFS filesystem.

$ pip search lafs
BaculaFS                  - Bacula Filesystem in USErspace
pytahoe                   - Python module for working with the Tahoe-LAFS filesystem.

$ pip search allmydata
allmydata-tahoe           - secure, decentralized, fault-tolerant filesystem

Notice that in the pypi namespace (which pip searches), there is a collision for tahoe.

Edits: wording, layout, formatting.