I also put dynamic_versioning as the backend so that one gets 0.14.whatever instead of 0.0.0 when using it locally, not sure whether that will mess up with something?

Mmm, that is dangerous: because e.g. master is at the moment definitely NOT 0.14 ... and as I was arguing in #417 with @evagroenendijk it is wrong to call master v0.15, because v0.15 might (or might not) contain even more breaking changes than now; so I think I prefer v0.0 - which should never appear in public codes any ways, but only for developers (who can deal with it)

which should never appear in public codes any ways, but only for developers

But in practice we have many fktables and ekos produced with 0.0.0.

But I do see the point, perhaps a better solution would be to (for a developing installation) get the commit without the tag?

Edit: perhaps I didn't explain myself well in the OP, 0.14.whatever is 0.14.6+<number of commits since tag>+<commit hash>

But I do see the point, perhaps a better solution would be to (for a developing installation) get the commit without the tag?

is it possible to just have the commit?

0.14.6+<number of commits since tag>+<commit hash>

or do we always need the full thing?

in any case we will need to adjust the legacy handling (initialised in #417) - specifically, we need to adjust this logic:

At the moment if EKO reads an object through a symlink and it is not in readonly mode, it will overwrite the symlink instead of the original file.

This PR modifies read so that it goes to the original file instead.

do you want to split this change from this PR? since I guess that change is uncontroversial (and does hopefully have no tail)

is it possible to just have the commit?

Yes. But

in any case we will need to adjust the legacy handling (initialised in #417) - specifically, we need to adjust this logic:

How does the legacy handler deals with 0.0.0 since it can be any version? (and adding the commit won't solve that)

(edit: in any case, I added the versioning because I thought it would have no downstream effects, since it does let's leave it be)

How does the legacy handler deals with 0.0.0 since it can be any version? (and adding the commit won't solve that)

ehm simply this

• if we do 0.14.whatever we have to change the conditions: i.e. check for data_version first
• if we do something else, we need to check if packaging likes that and then adjust the conditions if necessary