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:

• 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.)

[daira]

If we do this, I vote for tahoelafs as the module name.

[exarkun]

Most recent discussion I've heard in the vicinity of this idea is that instead of simply renaming the package containing the current Python codebase, a new Python package should be started with exposes a more coherent, publicly supported Python API (presumably entirely or primarily on top of the current Python API, all of which is generally considered internal). This would argue against the renaming described here, particularly any renaming to a desirable name which could be used for the package with a publicly supported Python API (where the name is a lot more valuable).