tahoe-lafs/trac-2024-07-25

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

New issue

Closed

opened 2008-12-16 22:45:29 +00:00 by zooko · 6 comments

zooko commented

2008-12-16 22:45:29 +00:00

Owner

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 source: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 source:setup.py accept an optional --application-name= argument, which if present will over-ride the PKG variable. Then have source: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.

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 source:setup.py to use the idiom of having a `PKG` variable, the way that [zfec's setup.py](http://allmydata.org/trac/pycryptopp/browser/setup.py) and [pycryptopp's setup.py](http://allmydata.org/trac/zfec/browser/zfec/setup.py) do, and make tahoe's source:setup.py accept an optional `--application-name=` argument, which if present will over-ride the `PKG` variable. Then have source: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.

tahoe-lafs added the

labels 2008-12-16 22:45:29 +00:00

tahoe-lafs added this to the 1.3.0 milestone 2008-12-16 22:45:29 +00:00

tahoe-lafs changed title from ~~prepend 'application-version' with the name of thsi particular application~~ to prepend 'application-version' with the name of this particular application

2008-12-23 21:35:59 +00:00

zooko commented

2009-02-03 20:35:40 +00:00

Author

Owner

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 commented

2009-02-04 02:28:39 +00:00

Author

Owner

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.

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 commented

2009-02-04 03:17:11 +00:00

Author

Owner

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

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

terrell commented

2009-02-06 00:16:45 +00:00

Author

Owner

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.

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 commented

2009-02-07 19:41:40 +00:00

Author

Owner

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 commented

2009-02-11 23:26:38 +00:00

Author

Owner

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

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

tahoe-lafs added the

fixed

label 2009-02-11 23:26:38 +00:00

zooko closed this issue

2009-02-11 23:26:38 +00:00