Enforcing dependencies in my own package

[macroscian]

I’m trying to write a package (my first, so apologies for ignorance) using Julia 1.0.1 that depends on the master version of an existing package Pages.jl, but am struggling to enforce this.
My current method is, in REPL

using Pkg
Pkg.activate(".")
Pkg.add(PackageSpec(name="Pages", rev="master"))

to build the Project.toml and Manifest.toml, the latter now containing

[[Pages]]
deps = ["HTTP", "JSON", "PlotlyBase", "Sockets", "Test"]
git-tree-sha1 = "a82e00554e2956010b207656d347ff4cae0dee05"
repo-rev = "master"
repo-url = "https://github.com/EricForgy/Pages.jl.git"
uuid = "7c165e09-dada-5b64-9fdc-39b801c58527"
version = "0.2.0+"

which seems to capture the requirement in the repo-rev. But when I attempt to load my package by

Pkg.add(PackageSpec(url="https://github.com/macroscian/uv_package"))

which is my (poorly written) package, which contains using Pages#master in the module, and also has the above Manifest.toml in the directory, it reports, under “Resolving package versions…” that it’s got Pages v0.2.0, which is a few crucial revisions prior to the head of master (but also an acceptable version in the manifest.toml above). As a double-check, the functionality of the third-party package is correspondingly not the latest commit.

I’ve almost certainly done something stupid and can’t spot the correct approach in the documentation, so any help would be greatly appreciated in ensuring that I can enforce the dependency on a later commit than is tagged
Thanks - Gavin

[fredrikekre]

1. You can’t depend on branches.
2. The Manifest.toml file in the package is not used at all (this is the most common misconception about how Pkg works).
3. using Pages#master is not valid syntax.

If you want to use a specific branch of one of the dependencies you need to explicitly add that branch, either before or after you add your own package e.g.

pkg> add https://github.com/macroscian/uv_package
[...]

pkg> add Pages#master

[Tamas_Papp]

@fredrikekre

The Manifest.toml file in the package is not used at all (this is the most common misconception about how Pkg works)

did this change? cf

Does Manifest.toml belong in the repository?

It might also be nice to have a manifest checked into package repos for a few reasons: So that you have at least one known good configuration that presumably passed tests and such. To keep the different developers of the package in sync using similar setups. Of course, 2 cuts both ways: it’s nice that all the devs have similar setups and they can upgrade in sync, but that means that there’s less testing of the package with different setups. Benefit 1 may be better accomplished with some kind …

[fredrikekre]

@Tamas_Papp

did this change?

No.

[Tamas_Papp]

I am confused, can you please help me understand why it was recommended to commit a Manifest.toml when it is not used at all?

[fredrikekre]

@Tamas_Papp

I am confused, can you please help me understand why it was recommended to commit a Manifest.toml when it is not used at all?

Stefan recommended it, I don’t (at least not as long as it is used by Pkg.test).

[Tamas_Papp]

You also recommended it, in another context (to be fair, along with Pkg.up())

So is that it isn’t used automatically, but Pkg.up() and Pkg.resolve() will use it if available?

[fredrikekre]

@Tamas_Papp

You also recommended it

Bit of a stretch to call that a recommendation

@Tamas_Papp

So is that it isn’t used automatically , but Pkg.up() and Pkg.resolve() will use it if available?

No, it will only ever be used if the Project.toml file of the package is the active project. This is not the case when you add a package, since you usually add it to some other environment (like the default v1.0 environment).

On CI however, we start julia with the package itself as the active project, and then we of course use the Manifest.toml that is in the package, if it exists. This is IMO bad, since you can have some weird configuration in there, and tests passes, but it will not be representative of the environment users use the package in.

[StefanKarpinski]

It’s useful because it provides a record of a working state for the project by itself, which is generally good to have. That’s why it should be used for CI: so that you know that a particular configuration worked. When using it as a dependency, it may not be used in that same configuration, but it’s still good to know some working configuration. Whatever project is using it as a dependency in a different configuration should check in its manifest, which then serves as a record of another working configuration. If that project does recursive dependency testing, then you not only know that the main project works and passes tests but also that all of its dependencies pass their tests. Of course, that level of testing is not required.

[chelseas]

IS this still true – you can’t depend on a main / master branch?