prepend 'application-version' with the name of this particular application

[zooko]

The 'application-version' string which is sent during version negotiation ought to start with some unique name for each application. So far we have two applications: tahoe-lafs and allmydata.com's tahoe-w32-client. The right way to fix this is probably to edit setup.py to use the idiom of having a PKG variable, the way that ​zfec's setup.py and ​pycryptopp's setup.py do, and make tahoe's setup.py accept an optional --application-name= argument, which if present will over-ride the PKG variable. Then have setup.py write the value of the PKG variable into the _version.py file, then, prepend that name to the 'application-version' string which is used for negotiation.

This needs to happen before the 1.3.0 release so that all LAFS implementors don't have to remember for the rest of their days that nodes which just called themselves "1.3.0" were actually tahoe-lafs nodes and ones that called themselves "3.3.0", or something were actually allmydata.com-tahoe-w32-client nodes.

Hopefully assigning to cgalvan.

[zooko]

I haven't heard from Chris in a while and he is in school now, so I'll probably take this ticket over from him for 1.3.0 if he doesn't speak up in the next day or two.

[warner]

Should this variable (as passed into setup.py) get recorded in the same file as the one created by 'darcsver'? Maybe yes, I just want to make sure we don't wind up having one tool clobber the output of a different tool.

I agree with your description above, that the "application name" should be kept in a different variable than the computed version number: the two can be concatenated elsewhere.

[zooko]

Good question. Yes, let's keep it in a separate file, named src/allmydata/_appname.py.

[terrell]

i'd suggest a naming convention for both these variables (appname and version), since they'll be concatenated (with a hyphen?).

is there a standing convention for the concatenation? does it matter at all? if it's only for 'printing' out, it probably doesn't matter - each of the initial variable values would still be available independently.

[zooko]

How about if the convention is that everything up to the first hyphen is the application name and everything after is the application version string.

[zooko]

7eb260a9cf6010a7 fixes this. That patch doesn't actually make the appname configurable by a run-time option to setup.py, but instead hardcodes it inside setup.py as the value of the APPNAME variable in module scope of setup.py. I'm going to close this ticket anyway, as this patch is sufficient to enable future backwards-compatibility, and the other issue about how to change the appname in your custom branch/fork/toothpick/variant/derived-product of Tahoe is a larger and separable issue about "branding".