Revise.jl doesn't appear to do anything

[thofma]

No, it is not unusual. You are doing everything right. The only problem was the old Revise version.

[pdeffebach]

Namespacing is hard when you include multiple modules. And you have to keep track of the dependency graph yourself when you get by with include-ing modules. If you include the same module twice, you will have two different modules with the same name floating around and this can cause lots of method errors. You should take care to only ever include code defining a module once.

[alice]

@thofma

No, it is not unusual. You are doing everything right.

Thanks! Sounds good then.

@pdeffebach

And you have to keep track of the dependency graph yourself when you get by with include -ing modules.

Yes, it’s quite annoying that I have to order my include statements so carefully. Though the same would apply with separate packages. I still need an acyclic dependency graph.

@pdeffebach

If you include the same module twice, you will have two different modules with the same name floating around and this can cause lots of method errors. You should take care to only ever include code defining a module once.

Yep, I got it

When you come from Rust, this part is relatively easy to handle because it maps quite nicely onto Rust’s distinction between mod and use. Namely the mod statement corresponds to include(...) and use corresponds to using/import.

(± minor details like mod automatically adding a module boundary and Rust actually preventing you from accidentally including the same file twice)

[MA_Laforge]

@alice

So the dev command is just to an alternative to using cd to navigate into the right directory and calling julia --project ?

Assuming I have a single package.

Not really:

• pkg>dev /path/to/SomePkg adds SomePkg to your current environment.

On the other hand,

• $julia --project /path/to/SomePkg makes SomePkg itself the current environment.

Projects/Environments

The Julia project (or environment) concept is used because scientists often need to explore phenomena by operating on data (ie running a series of calculations on the data).

This is an exploratory endeavour. We don’t necessarily know ahead of time where we are going, so we want an environment that just allows us to quickly process the data whichever way we think might be useful when an idea hits us (as you might know for yourself).

Eventually, we might start doing the same operation over and over again, and might at one point want a more conventional application to guide us through these more repetitive, known steps.

So, the julia --project SomePkg command is sort of analogous to using C/C++ makefiles to specify which libraries required to build your app (Sorry, I’m not familiar with Rust). Well, similar, in that it lists the required packages. Specifying a julia --project does not tell Julia how to compile or link things together the way makefiles do for C/C++ applications.

On the other hand pkg>dev /path/to/SomePkg is more like adding a makefile entry that adds SomePkg to your project. Also, pkg>dev implies you will be pointing to an actively developed .git repo (I don’t think it can point to any old directory).

…vs Conventional Applications

So if you are trying to build a conventional application (something people just launch and wait for a GUI or a result), then you might actually want to go the julia --project SomePkg route.

But I personally found this part of Julia to be a bit harder to understand for some reason. So I wouldn’t put energy on it until I felt more comfortable/happy with Julia.

But when you do want to explore this path, you might want to check out ConventionalApp.jl:
→ [ANN] ConventionalApp.jl

You don’t HAVE to use ConventionalApp.jl. It is basically just a utility module to help you create bash files, etc. But it gives you a solution on how conventional applications can be “generated” in a somewhat practical manner.