`version.py` in version control

[felixhekhorn]

RE the version file, I've reverted it back. imho there's no perfect solution, but what we do in NNPDF/nnpdf is to create a fake _version.py at build time, which gets ignored and imported by the real version.py https://github.com/NNPDF/nnpdf/blob/bf9a8ec9ab0cc3a4bb356732efc1c9077983b06d/pyproject.toml#L121

thinking about this perhaps it would be better if pre-commit would ensure that it gets back to 0.0.0? I wonder whether there's a ready made hook for that...

Originally posted by @scarlehoff in #470 (comment)

[felixhekhorn]

we should also check if this is the intended behaviour:

not sure why but poetry lock fills the version.py files

[evagroenendijk]

@felixhekhorn Could you elaborate a little bit on what is the problem? It's not entirely clear to me, at a first glance for me the versioning seems to work fine. Thanks!

[felixhekhorn]

The question is if that file should be under version control or not. At nnpdf (I understand from the comment above) this is not the case, but here it is - which one is correct? As you can check from #470 some manual work was needed (e.g. 03bcbc1) - why? Did I do something wrong there? Let's also check what other projects do.

This issue may or may not require changes in the code, but we should sort out the correct behaviour here and document that.

[evagroenendijk]

@felixhekhorn @scarlehoff

1. So at the moment at install the version.py file gets filled with the dynamic version, I implemented this last summer, I thought this would be what we would want? It shows the dynamic version and the data version. But if this is not what we want, I can easily change it to just show the current version (0.0.0). I now see that e.g. yadism does this last thing, so maybe I should change it?

2. About what is the "correct" way of doing the versioning, I see that this is really different for each nnpdf project. E.g. nnpdf defines this _version.py, while e.g. pinefarm defines the version directly in init.py. And so e.g. EKO and YADISM define a file version.py. In my opinion it does not matter so much, I think one is not really better than the other. So I think I would leave it like this (I guess if we want to make the method the same for all nnpdf projects we have to change it for a lot of them, but maybe it's not so much work). What do you think?

[scarlehoff]

Hi @evagroenendijk, the only thing I feel very strongly about is not having 0.0.0. Because when we do, we end up irremediably with grids, ekos and fktables with 0.0.0 as the version.

For the rest, I don't mind one way or the other. I also think there's no "correct" way. The way it is done in nnpdf felt easier / more maintenable to me as there's only the repository tag as the source of truth and this ensures that nnpdf-data and the nnpdf package are always synchronized (i.e., you cannot forge to update the version in one and not the other)

[evagroenendijk]

Hi @evagroenendijk, the only thing I feel very strongly about is not having 0.0.0. Because when we do, we end up irremediably with grids, ekos and fktables with 0.0.0 as the version.

For the rest, I don't mind one way or the other. I also think there's no "correct" way. The way it is done in nnpdf felt easier / more maintenable to me as there's only the repository tag as the source of truth and this ensures that nnpdf-data and the nnpdf package are always synchronized (i.e., you cannot forge to update the version in one and not the other)

Then I would suggest to leave it like this, unless @felixhekhorn thinks differently?

[felixhekhorn]

closed via #499