Recommendations for how to browse source code

[fredrikekre]

@Tamas_Papp

But if you are not using ProjectName , what’s the benefit/purpose of having a Project.toml with name = "ProjectName" and an UUID?

It has no effect on Julia, but could be good to name your projects regardless if you forget what that environment was about etc.

@Tamas_Papp

I also don’t quite understand what applications have to do with the package infrastructure. There is a single mention of the concept in the glossary, but otherwise it is not used, and I have not seen any examples.

Application is basically just another name for environment; when you run some code in the REPL with the default v1 environment you could call that your application.

[Tamas_Papp]

@fredrikekre

Application is basically just another name for environment; when you run some code in the REPL with the default v1 environment you could call that your application.

Thanks. It would be great to clarify this in the docs.

Does it make sense to think of the Project.toml and, ideally, the Manifest.toml, as a mechanism to achieve a consistent and reproducible environment to run a script (the “application”)?

[fredrikekre]

@Tamas_Papp

Does it make sense to think of the Project.toml and, ideally, the Manifest.toml , as a mechanism to achieve a consistent and reproducible environment to run a script (the “application”)?

Yea.

I group my applications as packages anyway, I think that is quite convenient, e.g. someting like

$ tree .
.
├── bin
│   └── run.jl
├── Manifest.toml
├── Project.toml
└── src
    └── Application.jl

2 directories, 4 files

where I can then using Application in bin/run.jl.

[e3c6]

Are there paradigmatic examples (e.g. public Github repos) of Applications out there that one can take a look at? Just to see how this feature is being used in the real world.

[StefanKarpinski]

@Tamas_Papp

I also don’t quite understand what applications have to do with the package infrastructure. There is a single mention of the concept in the glossary, but otherwise it is not used, and I have not seen any examples.

Even though explicit support for applications isn’t spelled out or developed, it needed to be thought through in advance to some extent: the project and manifest files are needed by both packages and applications. An application is essentially just something that has a project file and layout that Julia understands but which is not a package. It would be good to pick some conventions for applications like the ones that @fredrikekre has described, but it wasn’t necessary to do so in order to ship a new package manager. People will figure out good conventions themselves and then we can document those and converge on them as standards.

@Tamas_Papp

But if you are not using ProjectName , what’s the benefit/purpose of having a Project.toml with name = "ProjectName" and an UUID?

It’s not necessary, but why not? Applications usually have names and if you generate a uuid then it’s clear when different copies with differences are versions of the same application.

[Tamas_Papp]

@StefanKarpinski

It would be good to pick some conventions for applications like the ones that @fredrikekre has described, but it wasn’t necessary to do so in order to ship a new package manager. People will figure out good conventions themselves and then we can document those and converge on them as standards.

Thanks for the explanation. It would be great to have this mentioned somewhere in the Pkg manual where applications are described, eg as a note. I understand the context now, but I think that without it, the part about applications in the Pkg manual is somewhat confusing.