Replace Activation Header

[arnavs]

Instead of something like using Pkg; Pkg.activate(@__DIR__), change it to using InstantiateFromURL; activate_github("QuantEcon/QuantEconLecturePackages"). Could either do the last tagged release or master (@jlperla).

[jlperla]

Perfect! My feeling is that we should leave it as master for now, and maybe make a global move to a version tag once the notes and packages reach some sort of stability. It should be a simple search-replace if we keep the header clean.

To confirm, in the rst right now we have

Activate the project environment, ensuring that ``Project.toml`` and ``Manifest.toml`` are in the same location as your notebook

.. code-block:: julia

    using Pkg; Pkg.activate(@__DIR__); #activate environment in the notebook's location

And sometimes there is a using Linear Algebra, Statistics below that.

So how about the following global thing, added at the end of the Overview===== section

Setup
------

Activate the ``QuantEconLecturePackages`` project environment and package versions

.. code-block:: julia

    using InstantiateFromURL
    activate_github("QuantEcon/QuantEconLecturePackages")
    using LinearAlgebra, Statistics, Compat

Note that the using Compat has to happen after the activate_github to to make sure it uses the correct version. I like having those three libraries at the top, because they are usually required.

Another question is whether we should have this block before the first code, or universally at the top of every notebook or right below the Overview section of every lecture? I am starting to lean towards the second one. Thoughts?

[arnavs]

Second one sounds good to me as well. It's easier to maintain, since you never know where the first code block exactly is.

And makes sense re tags.

[jlperla]

OK. I will manually make this modification in the intro lectures I have been messing with, and at some point someone can go through the rest of them.

[jlperla]

---

Getting Started with Julia

• [x] Setting up your Julia Environment
• [x] An Introductory Example
• [x] Julia Essentials and more material
• [x] Fundamental Types with more material
• [x] Introduction to Types and Generic Programming

More Programming and Software Engineering Principles

• [x] Generic Programming
• [x] The Need for Speed
• [x] Plotting in Julia
• [x] Useful Libraries

Tools and Techniques

• [x] Linear Algebra
• [x] Orthogonal Projections and their Applications
• [x] LLN and CLT
• [x] Linear State-Space Models
• [x] Finite Markov Chains
• [x] Continuous State Markov Chains
• [x] A First Look at the Kalman Filter

Dynamic Programming

• [x] Shortest Paths
• [x] Job Search I: The McCall Search Model
• [x] Job Search II: Search and Separation
• [x] A Problem that Stumped Milton Friedman
• [x] Job Search III: Search with Learning
• [x] Job Search IV: Modeling Career Choice
• [x] Job Search V: On-the-Job Search
• [x] Optimal Growth I: The Stochastic Optimal Growth Model
• [x] Optimal Growth II: Time Iteration
• [x] Optimal Growth III: The Endogenous Grid Method
• [x] LQ Dynamic Programming Problems
• [x] Optimal Savings I: The Permanent Income Model
• [x] Optimal Savings II: LQ Techniques
• [x] Consumption and Tax Smoothing with Complete and Incomplete Markets
• [x] Optimal Savings III: Occasionally Binding Constraints
• [x] Robustness
• [x] Discrete State Dynamic Programming

Multiple Agent Models

• [x] Schelling's Segregation Model
• [x] A Lake Model of Employment and Unemployment
• [x] Rational Expectations Equilibrium
• [x] Markov Perfect Equilibrium
• [x] Asset Pricing I: Finite State Models
• [x] Asset Pricing II: The Lucas Asset Pricing Model
• [x] Asset Pricing III: Incomplete Markets
• [x] Uncertainty Traps
• [x] The Aiyagari Model
• [x] Default Risk and Income Fluctuations
• [x] Globalization and Cycles

Time Series Models

• [x] Covariance Stationary Processes
• [x] Estimation of Spectra
• [x] Additive Functionals
• [x] Multiplicative Functionals
• [x] Classical Control with Linear Algebra
• [x] Classical Filtering with Linear Algebra

Dynamic Programming Squared

• [x] Dynamic Stackelberg Problems
• [x] Optimal Taxation in an LQ Economy
• [x] Optimal Taxation with State-Contingent Debt
• [x] Optimal Taxation without State-Contingent Debt

[arnavs]

Done at 2c8e399 (including Setup subheader).

[Nosferican]

This requires that the users already have a Project.toml environment with InstantiateFromURL. I am not super sure about why the InstantiateFromURL pipeline operates as it does. My take would be something like Pkg#840. As for selected packages at the top by default, it goes against the previous decisions of only having the statements close to the code when possible and and having only the required packages per lecture. I would favor moving all the using statements at the beginning of each lecture and only packages actually used in that lecture.

[arnavs]

@nosferican The InstantiateWithURL will grab the environment if it isn’t present. Some potential pitfalls I see with what you posted are that (a) we may have multiple notebooks in the same directory with different requirements (i.e., we can’t call everything “Project.toml,”) and (b) we want these to be tagged or versioned (i.e., if I checked out a commit hash, no need to look for updates). Also, we need Manifest information as well for a fully reproducible environment.

I think LinearAlgebra and Statistics are exceptions, since they provide functions that users expect to work out of the box. And Compat is a case unto itself.

[jlperla]

These are orthogonal. I don't have any issue with us putting all of the using at the top of the lectures as soon as we get out of the intro to julia sections. The Instantiatewithurl has nothing to do with the using at all... it just makes sure that if you do using or even a ] add after activation, it will be grabbing a consistent set of versions of packages with compatible versions we can test.

The reason to embed them lower in the code for the introductory julia is that it helps students know which packages certain functions come from. I have already run into this with my class.