search

julia-actions / cache

A shortcut action to cache Julia artifacts, packages, and registries.
MIT License
38 stars 9 forks source link

Merge with `setup-julia`? #34

Open MilesCranmer opened 1 year ago

MilesCranmer commented 1 year ago

Could this be included inside the setup-julia action? For example:

- uses: julia-actions/setup-julia
  with:
    version: 1.8.2
    cache: true

and inside that cache dict, you could have the options available here. This is also what actions/setup-python has started to do.

I do think it should still remain a separate action, since this repo can be useful for caching the conda-forge version of Julia.

rikhuijzer commented 1 year ago

What would be the benefit? The argument that Python does it isn't very convincing.

MilesCranmer commented 1 year ago

Benefits: (1) less effort, (2) improved discoverability.

(1) Less effort:

The motivation of julia-actions/cache seems to be precisely because it is a little less effort than manually using actions/cache.

I think having it integrated to setup-julia be an extension of the same motivation.

(2) Discoverability:

It took me two years of using setup-julia before I realized this action even existed. Note how there are 10x more users of setup-julia than cache (this vs this), but I bet if it had been integrated with setup-julia, myself and others would have caching set up a while ago.

SaschaMann commented 1 year ago

Unfortunately it's not possible to just call this action from setup-julia, we'd have to reimplement it in Typescript. I'm not fully convinced that the effort would be worth it, especially because a standalone Julia-specific cache action would still be useful.

As far as I can tell, most people copy and paste workflows or use PkgTemplates.jl. In both cases, the effort and discoverability is the same between both approaches.

Note how there are 10x more users of setup-julia than cache (this vs this), but I bet if it had been integrated with setup-julia, myself and others would have caching set up a while ago.

Keep in mind setup-julia is much older than this action. Caching itself wasn't available on GHA on launch and for a long time the cache sizes were too small to be any useful.

I think there's a case to be made for uniting Julia-related actions in general. Back when we set most of them up, we decided to go with a number of smaller actions that can be mixed and matched as needed instead of one large action that covers 90% of use cases for Julia CI. That's also why julia-buildpkg, julia-runtest etc. are all individual actions.

With reusable workflows and composite actions, it would be possible to have both a large "do it all" action that covers most common use cases and more specific actions without too much overhead. I think I'd prefer that approach over including caching in setup-julia.

MilesCranmer commented 1 year ago

Unfortunately it's not possible to just call this action from setup-julia, we'd have to reimplement it in Typescript.

I hadn't realized this! That makes more sense why it would be more effort.

Although, maybe a simpler change would just be to have a setup-and-cache-julia action that just imports both. Or, you could move setup-julia into a setup-julia-core, and make setup-julia import both that and cache, and handle both caching and setup, with the only visible change to the user being what keys are available.

I think there's a case to be made for uniting Julia-related actions in general

I can see the interest in this, although I think buildpkg and runtest feel like they ought to be separate jobs.

Just think about how you would test a package manually at the command line. You would have a (1) package update command, (2) build command, and (3) a test command. I don't know of any programming language where you would need to run caching manually. Building and testing are usually separate commands that I need to run, though. I think this is why it feels so unintuitive to have a separate caching action for any GitHub setup job.

Keep in mind that it might become intuitive over time if you work with caching actions a lot - but encountering caching in GitHub actions for the first time was quite strange!

I don't feel too strongly either way though; I will trust your judgement on this. I really appreciate these various actions which have helped my projects immensely!