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

See also #2011 for changing the PyPI package name (which is easier).

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

[nejucomo]

FWIW my preferences for names are the following from most preferred to least:

1. distribution lafs, python module lafs
2. distribution tahoelafs, python module tahoelafs (I prefer tahoe-lafs but I prefer consistency more.)
3. distribution tahoe-lafs, python module tahoelafs
4. distribution tahoe-lafs, python module tahoe_lafs
5. other stuff...

I prefer the name "lafs" without "tahoe" because:

• It is concise.
• Every word in the acronym is relevant to its purpose and use, whereas "tahoe" is only related to the history. (How many times have you heard "why `tahoe'?")
• It is relatively available:
  • There is no lafs package in pypi.
  • There is no lafs package in debian 6.
  • There is no lafs package in Ubuntu: ​http://packages.ubuntu.com/search?keywords=lafs&searchon=names&suite=raring&section=all
  • lafs.org is a domain squatter, so presumably that domain could be purchased, and has few pre-existing associations / dead links. See: ​http://lafs.org
  • lafs.net is a legitimate organization unrelated to computing. See: ​http://lafs.net
• The acronym is the name of a filesystem. Short filesystem names are sexier.

Two drawbacks:

• The name "tahoe-lafs" is in widespread use. If we changed that, there'd be a near infinite amount of legacy reference tweaking. ie: "The lafs project (which used to be called tahoe-lafs) ..."
• The strangeness/uniqueness/unwieldiness of "tahoe" makes it more memorable.
• Changing the name (as daira points out) is busy work.

[nejucomo]

Replying to nejucomo:

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

I made #2011 which is a subset of this ticket and only about changing the PyPI name to match all the other names for consistency. It excludes changing python module names.

[daira]

This was blocked on #1159 which is now fixed.

Another drawback of "lafs" as the package name:

• I would like LAFS to refer to the protocol of which Tahoe-LAFS is an implementation. The package name should reflect the implementation. (If there were a general Python API to arbitrary LAFS implementations, lafs would make sense as the package name for that, but that's not what the current Tahoe-LAFS is.)