dependencies: use "foo" instead of "$(INST)/$(FOO)"

[jdemeyer]

Replace dependencies like $(INST)/$(PARI) by pari.

configure tarball (for buildbot testing): ​http://sage.ugent.be/www/jdemeyer/sage/configure-147.tar.gz

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​bbb688a

dependencies: use "foo" instead of "$(INST)/$(FOO)"

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​9145390

dependencies: use "foo" instead of "$(INST)/$(FOO)"

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f26772f

dependencies: use "foo" instead of "$(INST)/$(FOO)"

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​87d5afd

dependencies: use "foo" instead of "$(INST)/$(FOO)"

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​463d22a

dependencies: use "foo" instead of "$(INST)/$(FOO)"

[embray]

Ah, I was just thinking about this. Actually I had a broader proposal that I'd expand on later of cobbling all package metadata into a single machine-consumable file that I would like to use to better generate info on packages. But just improving the format of the "dependencies" file is a good start.

[fbissey]

I don't usually dwell in that area. It made me read some documentation. It does look ok and is a bit simpler.

[vbraun]

Lgtm but can you also merge in #20129

[jdemeyer]

Replying to vbraun:

Lgtm but can you also merge in #20129

Why? There is no conflict (openblas has no dependencies).

[vbraun]

Right, forgot about that.

[vbraun]

Conflicts with #20130

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​18d59bf	Move third-party packages to pkg-config blas
​de7efd2	Fix typo: use lapack.pc not blas.pc
​f1302b2	Bump patchlevels
​555b258	Iml version/patchlevel fix
​d7e720f	Merge commit '555b25811afe8da5d83c3ed6461e423a70f961f7' into t/20140/dependencies__use__foo__instead_of____inst____foo__

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​2e1cbc5

Use sed to transform dependencies from "foo" to "$(inst_foo)"

[jdemeyer]

Previous version didn't work because of phony targets in the dependencies. This new version still allows dependencies to be listed as foo. A small sed script transforms this to $(inst_foo).

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​383b1b4

Use sed to transform dependencies from "foo" to "$(inst_foo)"

[embray]

While you're at it, I've noticed that some packages don't have all their dependencies listed. I don't have an exhaustive list yet, but I just encountered that jsonschema is only included as a dependency of nbformat even though it's not listed as such.

Another one: mistune is a dependency of nbconvert.

[vbraun]

If we had a way of getting the dependency information into Python then it would be easy enough to compare with the pip dependency information for testing....

[jdemeyer]

Replying to embray:

jsonschema is only included as a dependency of nbformat even though it's not listed as such.

I don't understand this sentence

[embray]

The only reason jsonschema has an spkg is sage is because it's a dependency of nbformat, but nbformat does not list jsonschema in its dependencies.

[jdemeyer]

Maybe you are confusing run-time dependencies with build-time dependencies? The dependencies files are really only meant for build-time dependencies.

Anyway, this isn't what this ticket is about...

[embray]

Okay, that must be it then. I'm confused because some of the Python packages do list dependencies that I wouldn't think of as build dependencies (unless maybe the package doesn't import without them).

[jdemeyer]

Replying to embray:

I'm confused because some of the Python packages do list dependencies that I wouldn't think of as build dependencies (unless maybe the package doesn't import without them).

First of all, keep in mind that a test-suite is also considered "build-time". But it could very well be that packages list dependencies which are not strictly required. Usually, the time to build Python packages is negligible, so it's not so important.

[jdemeyer]

Regardless of all this, can somebody review this ticket please?