-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move from CLDR artifact to code generation #450
Conversation
Alternative to #687, which wasn't working well with PackageCompiler due to long paths still. This switches to a fork. A PR to merge this upstream has already been submitted: JuliaTime/TimeZones.jl#450 Clearly this is temporary, but since we use Manifests this should work ok.
Alternative to #687, which wasn't working well with PackageCompiler due to long paths still, leading to broken builds. This switches to a fork. A PR to merge this upstream has already been submitted: JuliaTime/TimeZones.jl#450 Clearly this is temporary, but since we use Manifests this should work ok.
Alternative to #687, which wasn't working well with PackageCompiler due to long paths still, leading to broken builds. This switches to a fork. A PR to merge this upstream has already been submitted: JuliaTime/TimeZones.jl#450 Clearly this is temporary, but since we use Manifests this should work ok.
@omus I would by happy to hear if you think this is a good way forward. |
Sorry, I've been rather swamped lately. I only have one major concern with this approach and is that each time there is a CLDR release we need to update TimeZones.jl. The issue with that is some users can end up in a situation where they may not want to update to the latest version of TimeZones.jl but do want to have the latest CLDR release. My personal preference would be to make a package akin to TZJData.jl which we can update independently from the TimeZones.jl code. With that said the rest of the approach does seem reasonable and maybe it's best to adopt this and break this into a separate package later. |
Co-authored-by: Curtis Vogt <[email protected]>
Thanks. Indeed I can see a benefit of having a separately upgradable package for this. I went for this change within the package to keep the PR somewhat small. I figured that when switching to a separate package we'd want to generate the code like this as well, so it is a good step to take regardless. If you prefer I'd be happy to create a separate package. I looked at some past cldr releases and saw that the Windows time zone IDs only change every few cldr releases. |
Would love to hear what I can do to land this. |
Bump :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this. I'm good with proceeding with this change once we complete a round of refactoring. It would be good to make the separate repo but I'm good to adopt this here first.
Co-authored-by: Curtis Vogt <[email protected]>
Thanks for the review! I completed the refactoring and regenerated using the latest CLRD release. Only left Could you approve the CI workflow? Locally on Windows it passes all tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just needs the io::IO
change and it looks like the benchmark Project.toml
may need some updating. We'll see what CI says about that on this run.
Co-authored-by: Curtis Vogt <[email protected]>
Yes, I see "Package TimeZones does not have Artifacts in its dependencies". This looks like it is due to |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #450 +/- ##
==========================================
- Coverage 92.95% 91.60% -1.36%
==========================================
Files 40 37 -3
Lines 1845 1667 -178
==========================================
- Hits 1715 1527 -188
- Misses 130 140 +10 ☔ View full report in Codecov by Sentry. |
Since [our contribution](JuliaTime/TimeZones.jl#450) is merged upstream and released, we can stop using a fork. We don't directly depend on this package, but it is an Arrow.jl dependency. Therefore it can now be removed as a direct dependency, which was only done to be able to specify compat and point it to a fork.
Fixes #373, based on the proposal outlined in #373 (comment). The main benefit is to remove a large artifact download on Windows, which has long paths, leading to issues with PackageCompiler.
This removes the
WindowsTimeZoneIDs module
. Even though the generated dict is only used in Windows, I decided to remove the conditionalSys.iswindows
includes since these translations could perhaps be useful on other platforms as well.