Skip to content
This repository has been archived by the owner on Sep 10, 2023. It is now read-only.

Update Project.toml #56

Merged
merged 3 commits into from Jan 17, 2021
Merged

Update Project.toml #56

merged 3 commits into from Jan 17, 2021

Conversation

rikhuijzer
Copy link
Contributor

@rikhuijzer rikhuijzer commented Jan 4, 2021

This draft PR aims to be a central place to discuss how to incorporate the Franklin switch into the existing package setup. Here, we can discuss what version we should bump to and what the changelog in the README should show. (Note that many changes are moved in via PRs, so they will also be visible at https://github.com/StatisticalRethinkingJulia/TuringModels.jl/releases.)

In essence, the big changes are

  • Show the output via Franklin.jl and Literate.jl
  • Simplify code
  • Use names for models instead of numbers
  • Fix multiple models
  • Let CI fail if an error occurs during build (to avoid manually having to check >20 webpages)
  • Update README

@rikhuijzer
Copy link
Contributor Author

If we tag the current version, people will not be able to write

using TuringModels

to load the modules. Is that a problem? Do people depend on that functionality, you think? In the examples, I try to clearly indicate what dependencies we need where, so that people can easily understand what is going on.

@goedman
Copy link
Member

goedman commented Jan 4, 2021

I wonder if this setup runs as a project. I think that is important, i.e. I run TuringModels as follows:

$ tm      # or tm15, etc.

With in my .zshrc:

alias tm15="clear; cd ~/.julia/dev/TuringModels; j15 -i -e 'using Pkg; pkg\"activate .\"'"
alias tm="clear; cd ~/.julia/dev/TuringModels; j -i -e 'using Pkg; pkg\"activate .\"'"

In @1.5, @1.6 and @1.7 I only have Pkg, DrWatson, Pluto and PlutoUI. No other packages.

@rikhuijzer
Copy link
Contributor Author

Ok 👍 That should be possible. I'll start working on that

@goedman
Copy link
Member

goedman commented Jan 4, 2021

Maybe this should be V2 of TuringModels? Is your plan to hide the Franklin code in a
docs subdirectory with it's own Project.toml? (Just some thoughts, not musts!)

@rikhuijzer
Copy link
Contributor Author

rikhuijzer commented Jan 4, 2021

Maybe this should be V2 of TuringModels?

That's a great idea! Especially because we are going to support more models from Edition 2.

I wonder if this setup runs as a project.

I'm now switching back to using Literate in combination with Franklin like, for example, at https://github.com/alan-turing-institute/DataScienceTutorials.jl. An example for globe-tossing is now in the master branch. Does this approach work for you again? 😄

Is your plan to hide the Franklin code in a docs subdirectory with it's own Project.toml? (Just some thoughts, not musts!)

I think that is a very fair point. I also don't really like so many top level folders/files. Technically, it is possible to move more files into a folder called docs or something. The only counterargument that I can think of is that it is non-standard. Even https://github.com/alan-turing-institute/DataScienceTutorials.jl does it like that. What would you prefer?

@goedman
Copy link
Member

goedman commented Jan 4, 2021

I have no strong preference either way, so you decide. I think it is far more important to get the models up to date and documented for the 2nd edition. For Turing the 1st edition models are also less important. Making it v2.x.y indeed makes a lot of sense and folks can always add TuringModels@1.1.3 if they want to go back.

I also like your idea to name the models.

@rikhuijzer
Copy link
Contributor Author

I think it is far more important to get the models up to date and documented for the 2nd edition.

Check.

For Turing the 1st edition models are also less important.

You mean for the developers of Turing.jl or for StatisticalRethinkingJulia/TuringModels.jl?

I also like your idea to name the models.

Thanks!

For some models, I saw that McElreath has only updated the numbers in the model. I would prefer to link both editions to the same model (for example, globe-tossing.jl) and set the numbers to the newest version in the book. What do you think about this?

@goedman
Copy link
Member

goedman commented Jan 5, 2021

I meant for TuringModels.jl.

Yes, the mapping is sometimes rather obscure. In the 2nd edition some models are missing (m4.5 and m5.6 come to mind). It's up to you, linking is fine. The 2nd edition of the book is now out for about a year, if it gets too complicated we should focus on the 2nd edition I think.

@goedman
Copy link
Member

goedman commented Jan 5, 2021

Rik, I think your short-changing yourself in the CC note at the bottom of the pages, maybe it should be "Rik Huijzer, Rob J. Goedman and contributors"? The pages are looking great!

@rikhuijzer
Copy link
Contributor Author

Is your plan to hide the Franklin code in a docs subdirectory with it's own Project.toml

I've been thinking a bit about the last part, and think we should be better of with only having one Project.toml file for the static site and the scripts. Also, Franklin by default uses a Manifest.toml, but I think we can avoid committing the Manifest.toml in the repostory if we use [compat]. The convention in Julia is that breaking changes will get a much higher version number, that is, they go from 1.1.0 to 1.2.0 and not 1.1.0 to 1.1.1. So, when using only [compat], we should be able to guarantee for the static site and the users that everything works. (And otherwise, we should notice that the static site breaks.)

@rikhuijzer
Copy link
Contributor Author

Rik, I think your short-changing yourself in the CC note at the bottom of the pages, maybe it should be "Rik Huijzer, Rob J. Goedman and contributors"? The pages are looking great!

Thanks! When #58 is merged, it will be "Rob J Goedman, Rik Huijzer and contributors". I've put you first because you put more effort into this project!

@rikhuijzer
Copy link
Contributor Author

rikhuijzer commented Jan 16, 2021

Ok. I've now moved over all the models from the scripts, gave them a nice name and cleaned up the code a bit. I think we're ready to call it v.2. @goedman Can you merge this PR if you agree?

@rikhuijzer rikhuijzer marked this pull request as ready for review January 16, 2021 18:47
@goedman goedman merged commit f6f8eb9 into master Jan 17, 2021
@goedman goedman deleted the increase-version branch January 17, 2021 13:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants