Add Manifest.toml and CompatHelper about turingtutorials HOT 9 CLOSED

I would appreciate it. Is there a way to attach it to an update in the Manifest?

Okay. I'll start to work on it and add a Manifest.toml.

from turingtutorials.

it would be cool if the tutorials would be rebuilt automatically but it is even helpful if this has to be done manually, I think

@cpfiffer Is there a particular reason that the docs are not built with CI? It frightens me a bit when I look at a tutorial and see "Julia Version 1.5.3", which means it's likely built months ago.

from turingtutorials.

It would be easier to rerun and debug the examples if the Manifest.toml would be checked in as well.

In my experience with my blog (https://github.com/rikhuijzer/huijzer.xyz) and TuringModels.jl (https://github.com/StatisticalRethinkingJulia/TuringModels.jl), just the Project.toml with compat entries should be enough if you rerun everything about every week. I've never gotten into major issues, which I think is because package maintainers stick to semantic versioning quite well.

from turingtutorials.

It's a bit wasteful to rerun everything every week, and it's also not guaranteed that package updates (even according to Semver) don't break tutorials (e.g. additional exports in some package might cause ambiguity errors). IMO both Manifest and Project files should be added to make it reproducible, and we should use the same CI setup as SciMLTutorials and SciMLBenchmarks (#118 (comment)).

from turingtutorials.

It's a bit wasteful to rerun everything every week, and it's also not guaranteed that package updates (even according to Semver) don't break tutorials.

With that logic, we could also stop using CI. I would argue that the time wasted by people on manually running tutorials and messing around with broken tutorials is more wasteful. But, do these tutorials take hours to run? Maybe that's what I'm missing here.

With "every week" I meant "reasonably regularly". My point is that, in my experience, package updates do not often break runs. And if they do, it might actually be good to detect it soon and fix it instead of trying to find the culprit months later. For example, my blog has been running with Query, AlgebraOfGraphics (used to be Gadfly), MLJ, MLDataUtils, Turing and more for quite a while. I've never encountered much issues with it. And arguably, if a tutorial is expected to be so fragile, shouldn't it be a good idea to make them more robust?

from turingtutorials.

Let me put it differently: let me know if a PR on CI for the TuringTutorials would be appreciated. That's why I was asking in the first place.

from turingtutorials.

There's no reason for rerunning tutorials if the package versions are fixed with a Manifest file which IMO we should do since otherwise the setup is not reproducible. CompatHelper will bump package versions and rerun the tutorials if new breaking versions are available. Additionally, one could also update Manifest files at irregular times automatically if desired but it seems less important.

from turingtutorials.

Let me put it differently: let me know if a PR on CI for the TuringTutorials would be appreciated. That's why I was asking in the first place.

I would appreciate it. Is there a way to attach it to an update in the Manifest?

from turingtutorials.

@rikhuijzer Check out what we did in KernelFunctions.jl to parallelize the creation of the examples (it's with Literate.jl but I suppose it's easily adaptable to Weave.jl) : https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/blob/master/docs/make.jl

from turingtutorials.