#1950 closed task (wontfix)

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

Reported by: warner Owned by:
Priority: normal Milestone: 2.0.0
Component: packaging Version: 1.9.2
Keywords: cleanup Cc:
Launchpad Bug:

Description (last modified by daira)

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

Change History (12)

comment:1 Changed at 2013-04-22T21:43:00Z by daira

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

comment:2 Changed at 2013-04-22T21:49:03Z by 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".

comment:3 Changed at 2013-04-22T22:14:00Z by 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.

comment:4 Changed at 2013-04-23T05:17:33Z by daira

  • Keywords cleanup added

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

comment:5 Changed at 2013-04-23T08:00:52Z by 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.

comment:6 follow-up: Changed at 2013-07-04T16:19:16Z by nejucomo

  • Description modified (diff)

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.

Last edited at 2013-07-04T16:34:13Z by nejucomo (previous) (diff)

comment:7 Changed at 2013-07-04T16:32:50Z by 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:
  • 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.

comment:8 in reply to: ↑ 6 Changed at 2013-07-04T16:42:52Z by 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.

comment:9 Changed at 2014-10-27T01:45:34Z by 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.)
Last edited at 2014-10-27T01:46:05Z by daira (previous) (diff)

comment:10 Changed at 2014-12-04T13:52:38Z by daira

  • Description modified (diff)
  • Milestone changed from undecided to 2.0.0

comment:11 Changed at 2015-04-12T22:57:32Z by daira

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

comment:12 Changed at 2020-01-21T20:52:10Z by exarkun

  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.