ExHammer / hammer

An Elixir rate-limiter with pluggable backends
https://hexdocs.pm/hammer/
MIT License
738 stars 42 forks source link

Remove .tool-version to unpin elixir version used for development #77

Closed sato11 closed 8 months ago

sato11 commented 8 months ago

The presence of .tool-version makes those who use asdf unable to proceed with running some basic mix tasks like deps.install and test.

Since this repository targets multiple elixir versions, I bet it makes more sense to get rid of the .tool-version so each developer can choose which version to use when debugging.

epinault commented 8 months ago

this is only for developping this library. how is that a problem? I use ASDF and don t have any issues. the point of is to say that we are developping currently in that version, while we test and maintain for up to some version

sato11 commented 8 months ago

Thanks for the reply.

Well, let me repeat what I wrote it in the description above since I think it answers your concern: I thought it felt odd that I couldn't run any tasks unless I removed .tool-version or I re-installed the older version of Elixir. I actually removed this file so I can start touching the project with 1.16, when I thought it makes sense to change it upstream.

From another point of view, it also feels unclear how strict you want to enforce the version specification. Since .tool-version I bet only affects those who use asdf, you must require everyone to use asdf if you really want to pin the version. Otherwise the presence of .tool-version doesn't feel like a helpful explicitness but rather an absurdity imposed on us who use the newer versions of Elixir through asdf.

If this was a personal or proprietary project of yours, I'm fine with it. But for an open project like this, I think it makes sense to accommodate a range of versions. What do you think?

epinault commented 8 months ago

Well, let me repeat what I wrote it in the description above since I think it answers your concern: I thought it felt odd that I couldn't run any tasks unless I removed .tool-version or I re-installed the older version of Elixir. I actually removed this file so I can start touching the project with 1.16, when I thought it makes sense to change it upstream.

So the .tool-version is mostly ASDF and some other version manager support that (example rbenv). If none of your version language manager support it, it won t care

IF you have 1.16 on your box, that s fine but you are missing the fact that for example the formatter between1.13/1.14 to 1.15 format files differently (just one example amonst other reasons) .So now the code would be formatted differently and fail the check depending on which version people are developping on.

Also I have not yet added 1.16 as it was recently released so my default would still be 1.15 for developing that project at the moment and have not had time to work on it since the update I did for 1.13.. But having a set version for developing, there might be reasons as mentioned earlier. Being compatible to run is different than developing that version on.

Matter of fact I want to retire 1.12 because or the change for the Logger (warn vs warning). It would not run in 1.12 anymore.

If you want to dev on that project, all you have to do :

asdf install in the project folder, and it will install all the dependencies needed for you to develop without having to worry how it s running for other projects. Which is what ASDF is about, being able to support multiple version per projects. If you don t use ASDF, then at least it documents the version it was currently used to develop on

From another point of view, it also feels unclear how strict you want to enforce the version specification. Since .tool-version I bet only affects those who use asdf, you must require everyone to use asdf if you really want to pin the version. Otherwise the presence of .tool-version doesn't feel like a helpful explicitness but rather an absurdity imposed on us who use the newer versions of Elixir through asdf.

While I appreciate your feedbacks, what you call an "absurdity imposed" is your opinion . I would appreciate more of collaborative tone than judgemental .I took over this project last year that was dying and nobody seemed to care about it back then as my company could not upgrade further due to dependency chain issues. I spent time through the PR that were open added the one that seemed like a good idea . But this project needed serious maintenance. And I had to do that outside of my work hours to maintain it. While some decision may not suit you or be optimal for everyone, I am open to new ideas but in a more positive and collaborative manner.

you can use the latest and greatest in your box, just not all library will suit you when you work on them. And why ASDF makes it easy for you to collaborate by just doing "asdf install". Migration and test to 1.16 have not been yet so until then, i cannot assume it all works .

If this was a personal or proprietary project of yours, I'm fine with it. But for an open project like this, I think it makes sense to accommodate a range of versions. What do you think?

I actually treat personal , proprietary or OSS with the same quality I would for any of my projects. I don t make less qualtiy because of personal or other label. I prefer to add the most quality I can for all my projects

that being said, I will up it to 1.15 for now . I am not planning on removing it because

Older version are merely supported for runtime , not for developing

epinault commented 8 months ago

closing for now as I don t believe this is an issue. Feel free to reopen if you feel that it s needs a different approach or have a different solution