Hacker News Reader

Comment by dnautics | Hacker News Reader

I've thought about this problem, quite a bit, and I think that productionizing Julia would require at least a few additional things above your criticisms about error codes.

1. Get rid of global dependencies. Store all of your dependencies in a project local deps directory with a project lock file.

2. Opinionated file system structure. Maybe you don't need this in one-off scripts but definitely for some sort of "project" layout

3. Force all packages in the package manager to obey these constraint.

The ship may have already sailed on 3), sadly.

View on HN

You are describing every Julia package. These are the rules of the package manager.

1. Every package must declare it's dependencies (and to register must declare compat bounds on them, and good devs do that always anyway) 2. Every package must have Project.toml in the base directory, source code goesin `src`, test code goes in `test`, documentation goes in. `docs` (and more structure there if using Documenter.jl) What more could one want? If a package needs more folder structure within `src` then it should be multiple packages. 3. These are the rules, done.

Further you are describing every sensibly done julia application.

Basically no seriously Julia developer uses the global environment for anything but dev-tools, like BenchmarkTools or ProfileView. Certainly one does not depend on the content of them for any reused code -- that is what Project.toml and Manifest.toml is for.

> every sensibly done julia application.

Can you point me to some documentation on those best practices. My girlfriend - architectural acoustics consultant - is working on a project in Julia and is having a hell of a time managing dependency shift underneath her program (also she barely knows how to use git).

Sadly I can not point you to a single piece of documentation that covers everything. That's definitely an area Julia can improve. Writing down the things "everyone" does, so newcomers don't have to learn them again.

The Pkg manual doesn't have a tutorial on standard practice. But it's worth reading the compat section and making sure to always set your compats https://julialang.github.io/Pkg.jl/v1/compatibility/

And the section on creating one's own project. So as not to need to use the global environment. And alternative to using `activate` after starting Julia (and my preferred way) is to start Julia with the `--project=.`

https://julialang.github.io/Pkg.jl/v1/environments/#Creating...

And can go further and create projects via PkgTemplates which is was "everyone" does. Because a good project looks just like a package (one might as well consider them synonyms when looking for thus kind of advice) https://github.com/invenia/PkgTemplates.jl/tree/v0.6.3

It's got anaconda-like project spaces? While I can see why they did that because it's what people are used to... That's a terrible, terrible choice (I joke there's a reason why docker got invented and it's that conda is awful). Why not just put deps in the project directory instead of in ./julia/..

What's the issue about global dependencies that you're trying to solve? For my production system, we manage version changes by way of Manifest.toml so that we don't get any surprises.

I agree that an opinionated file system structure is nice. Julia already wants you to put source code inside `src` but then underneath you are free to do whatever you want. We generally manage this via coding convention since people can never agree on a standard.

Reply on news.ycombinator.com