Project.toml causes Travis to fail with: ERROR: Cannot develop package with the same name or uuid as the project

Yesterday I finally added a Project.toml file to my repo. Had to do it directly via the Github page because the attempts to do that via a PR always resulted in

ERROR: Cannot develop package with the same name or uuid as the project

Today, I had to do a small fix to the Project.toml file and now again the builds are broken due to the same error.

What might be causing this? The Project.toml was generated with thw gen_project.jl script.

I believe you need to change this line to

julia -e 'using Pkg; Pkg.build(); Pkg.test(; coverage=true);'

(or leave the script section empty to use the default build).

Yes, you are intentionally using a custom testing script instead of the default. Unless you have specific needs it is usually easier to use the defaults.

1 Like

Thanks. That allowed to advance a bit, but then it opened the door for several other errors. First, it started to complain about a missing Pintf dependency. Added that to Porject.toml. Then it was the missing Test package – managed to solve it too. Now it complains about ERROR: LoadError: ArgumentError: Package LinearAlgebra not found in current path: - Run `import Pkg; Pkg.add("LinearAlgebra"). Where do I find the uuid of it?
Was not the role of the gen_project.jl script to find all of these?

You can just do add LinearAlgebra in Pkg REPL mode and then move the Project entry down to extras and add to test target.

Sorry, don’t understand what you mean. This is what I currently have in Project. What do I need to add and where?

[deps]
Printf = "de0858da-6303-5e67-8744-51eddeeeb8d7"

[compat]
julia = "1"

[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["Test"]

If you do add LinearAlgebra with that project active you see that you get an entry into [deps]. Move that down to extras and add LinearAlgebra to the test list (same as Test).

Thnks, I think I got it now but meanwhile solved the issue by removing the need of LinearAlgebra from my test suit.

Uff, and thinking that are people saying the new registering method is easier then AttoBot…

This has not that much to do with AttoBot or Registrator but with the package manager itself (as you can see by CI failing which is before Registrator is involved).

Yes, but this all started when the Prokject.toml didn’t like my previously working .travis.yml script