Allow local versions of database

[hughjonesd]

If I want to use - e.g. - "pt" for points, not pints, I can do that with install... functions. But now suppose a package does that, but another package wants to use "pt" for pints. I don't think at present that will work. It would be nice if different namespaces could have their own versions of the udunits database.

[Enchufa2]

This was in part discussed in #134. You can take a look there for a bit of background.

I'm not sure how this should work. Suppose that package {A} and package {B} depends on {units}. Following your example, suppose that {A} wants "pt" to be "pints" and {B} wants "pt" to be "points". Then the user wants to use both {A} and {B}. What should happen if the user wants to define 3 "pt"? What if the user takes any unit produced in {A} and uses it in a method of {B}?

[hughjonesd]

Interesting discussion.

I think there is a distinction between packages using units internally, and exposing them to the user. For example, suppose I am a radiologist. I load a package that uses units to deal with "rem" (Roentgen equivalent man), sieverts etc. Perhaps I have data which is in these units, and the package accepts them as inputs. Then I present my data using, e.g. a web application. I load a package which uses units internally. It redefines "rem" to mean the CSS unit "root element em" but I don't need to worry about that, because it is using its own copy of the database.

The radiology package, which accepts units as inputs from the user, could either use its own copy, or could use the global database as now. Using the global database means the user can easily add new definitions, which is useful. The corresponding risk is that definitions can be silently overridden if another package is using the same database.

[edzer]

I think the design of udunits2 is to have a single, global, coherent units database. If you mess it up, you mess it up, and that's up to you. You can't mess it up locally.

[Enchufa2]

I also thougth about multiple units systems in the past, but nowadays I tend to agree with @edzer. If a package just wants to internally deal with some specific non-standard units (i.e., inches, points, lines..., as {grid} does), then {units} is of no benefit. If instead you want to export such functionality and make it available through {units} to the user and other packages, then as soon as you have your own units, everything is messed up, with or without multiple databases.