Closed johnnychen94 closed 5 years ago
since Project.toml can be ambiguous when Julia is just one tool used in the whole project.
Why not use JuliaProject.toml
then? I am a bit reluctant to add features here that does not exist in Pkg itself.
Alternatively you could just use requirements.txt
(why is that not ambiguous though?) and execute
$ jlpkg add $(cat requirements.txt)
I'd like to explain the ambiguity I said:
We add items to Project.toml
(not other names like JuliaProject.toml
) mostly by Julia. If it's all about julia, then Project.toml
is more convenient and explicit than requirements.txt
.
When julia is only a part of the whole project, it's not so good to still use Project.toml
, and if we need to support jlpkg --project=path --file=JuliaProject.toml
, there's a copy&paste step between Project.toml
and JuliaProject.toml
. On the other side, julia_requirements.txt
doesn't need this step.
I think jlpkg add $(cat requirements.txt)
does most of my expectation, I'll check it, thanks.
I mean, Pkg already supports JuliaProject.toml.
Good to know that!
I'm closing it now since I don't have any further questions.
Hi,
I'm asking this because I'm writing some CI script in which I need to add a bunch of Julia packages to its base project (
v1.1
in my case).Instead of hard-coding the dependent package names in
.travis.yml
or.gitlab-ci.yml
, I want to hold them in either aProject.toml
orrequirements.txt
file.The usage in my mind is:
I prefer the pip way
requirements_julia.txt
sinceProject.toml
can be ambiguous when Julia is just one tool used in the whole project.How do you think?