Ruby Version - necessary for tzf gem

[alterisian]

We're using the tzf gem to establish who is in the current timezone when the mob is active.

And also the idea, would be for the next timezone too.

I guess there's two aspects to the problem. Until now, a version has not mattered.
Now we find some later versions do not work, and some earlier versions are preferred.
We have a .ruby-version file in the repo now, and this needs to be set to the version that does work for this gem.
(My understanding is that if we have this, then we do not need the one in the Gemfile - happy to be corrected though).

Ruby 3.0.2 seems to work on Ubuntu 22, with rbenv.
I think myself and @Animesh-Ghosh confirmed this on codespaces.
However, when @Georgy5 and @mmiy55 tried the version was still going to 3.1.4
(We're unsure if this is because codespaces was started in the main branch.)
TODO-check with .ruby-version set to 3.0.2 that codespaces does not load 3.1.4

Important to get this feature branch, merged in asap, then we do not have the confusion problem at least.
(Maybe generally we try to work on main unless there's a production server involved, but a branch could be considered max a 2 week lifespan?)

In our exploring of timezones I've found https://timeanddate.com to be the best site. It also has an api we could use as an alternative: https://www.timeanddate.com/services/api/

[Georgy5]

I'm giving my feedback now on trying to rub the project locally, not on Codespaces:
When running bundle install localy with Ruby version 3.0.x, the TZF gem is installed with no issues.
When I try to run ruby helloworld.rb however, I get an error on line 29 which requires the TZF gem.
This is the same for @mmiy55 and me.

[Georgy5]

When I try to run ruby helloworld.rb with Ruby 3.0.x I get an error on line 29 which requires the TZF gem. This throws a "Could not open library error"
I tried with Ruby 3.0.1 as well as with version 3.0.5

[Georgy5]

I would also note that the Gemfile.lock file in the main branch has TZF version (0.2.5), while the TZF version in Gemfile.lock of the "availability_tweet" branch is tzf (0.1.0)
When I ran bundle install on the main branch with Ruby 3.0.x, it was installing TZF version 0.1.0 on my machine. I saw the same with @mmiy55 when we paired last Thursday.

When I run bundle install on the main branch with Ruby versions higher than 3.0 I've seen Bundler try to intall versions 0.2.6 and 0.4.0 of TZF. However running bundle install or gem install tzf with Ruby 3.1.x or 3.2.x always fails during install while trying to build the gem.
I get a "Unable to find libclang" error. Miriam got a similar error, but Mac specific.

[Georgy5]

The TZF Repo says that it uses the tzf-rs Rust library.
Even though it seems that Rust is only a requirement for development, I have Rust installed since I installed Ruby 3.2.2 also and it uses the YJIT compiler.

It's not explicit in this screenshot, but I have Rust installed. However, installing TZF still fails

"couldn't find any valid shared libraries matching..." libclang

[Georgy5]

I wonder if TZF has been working for @alterisian and @Animesh-Ghosh because an older version was installed (version 0.1.0 or 0.2.5) in combination with using Ruby version 3.0.1 or 3.0.2 ?

However, I have not yet tried bundle exec ruby helloworld.rb with Ruby 3.0.x

[Georgy5]

I did try GitHub Codespaces on Thursday on the original Repo. Codespaces starts on the main branch by default and it had Ruby version 3.1.4 installed. This also would not work with TZF with bundle install

That is my feedback thus far.

I believe that we could setup some defaults for our codespaces dev containers for this project, but I havn't looked into further.
https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration

[Georgy5]

I believe that in the current state the TZF gem poses a barrier to entry for anyone new joining our project. Like @alterisian mentioned it'd be important to get this sorted.

[Georgy5]

Development Containers & GitHub Codespaces should kill the “works on my machine” problem.
May be we can setup codespaces for this project, with the right Ruby version and all
(May be it's as simple as having the .ruby_version file in the main branch ¯_(ツ)_/¯ )
Should I add an issue for this? -codespaces setup

[alterisian]

We should only have the main branch.
Looks like the scheduled Sunday task is also having tzf / ruby version issues ( https://github.com/alterisian/helloworld/actions/runs/4972594037/jobs/8897888988 )

Lets merge all branches into main on Wednesday this week, and fix at ruby 3.0.2 via the .ruby-version file only.

If we use temporary feature branches can they be merged at the end of the session. Dev on main is fine if we do small and tested steps :)

[alterisian]

Which method on spike is useful aninmesh? Perhaps we can adapt the code to use the timeanddate api. Lets merge it into main asap, and kill the branch.

[Animesh-Ghosh]

Which method on spike is useful aninmesh?

Didn't get this.

Perhaps we can adapt the code to use the timeanddate api. Lets merge it into main asap, and kill the branch.

Yeah, we can switch to this, not sure if their API is paid or not. One work-around that I found was maybe utilizing this endpoint however their README may or may not be reliable.

[Georgy5]

Hi all
I came across something that I think will be useful, the Bundler install_if method. With it we can make TZF optional based on mieeting a condition. for example

install_if -> { `whoami`.strip == 'alterisian' } do
  gem "tzf"
end

I don't know yet which condition makes most sense, but then we could all use the same Gemfile again without TZF causing issues for some.
Will look into this more this weekend.