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

New Issue

warner · 2013-04-22T21:19:00Z

warner commented

2013-04-22 21:19:00 +00:00

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

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

warner added the

labels 2013-04-22 21:19:00 +00:00

warner added this to the undecided milestone 2013-04-22 21:19:00 +00:00

daira commented

2013-04-22 21:43:00 +00:00

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

warner commented

2013-04-22 21:49:03 +00:00

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

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 commented

2013-04-22 22:14:00 +00:00

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.

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 commented

2013-04-23 05:17:33 +00:00

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

2013-04-23 08:00:52 +00:00

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.

The [PEP on naming modules and packages](http://www.python.org/dev/peps/pep-0008/#package-and-module-names) 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](http://en.wikipedia.org/wiki/Tahoe_%28disambiguation%29), 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 commented

2013-07-04 16:19:16 +00:00

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.

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 commented

2013-07-04 16:32:50 +00:00

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

distribution lafs, python module lafs
distribution tahoelafs, python module tahoelafs (I prefer tahoe-lafs but I prefer consistency more.)
distribution tahoe-lafs, python module tahoelafs
distribution tahoe-lafs, python module tahoe_lafs
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.

FWIW my preferences for names are the following from most preferred to least: 1. distribution `lafs`, python module `lafs` 1. distribution `tahoelafs`, python module `tahoelafs` (I prefer `tahoe-lafs` but I prefer consistency more.) 1. distribution `tahoe-lafs`, python module `tahoelafs` 1. distribution `tahoe-lafs`, python module `tahoe_lafs` 1. 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 commented

2013-07-04 16:42:52 +00:00

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.

Replying to [nejucomo](/tahoe-lafs/trac-2024-07-25/issues/1950#issuecomment-91485): > 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 commented

2014-10-27 01:45:34 +00:00

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

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

tahoe-lafs modified the milestone from undecided to 2.0.0

2014-12-04 13:52:38 +00:00

daira commented

2015-04-12 22:57:32 +00:00

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

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

exarkun commented

2020-01-21 20:52:10 +00:00

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

exarkun added the

wontfix

label 2020-01-21 20:52:10 +00:00

exarkun closed this issue

2020-01-21 20:52:10 +00:00

Sign in to join this conversation.