Update subpath display

[rjbou]

Some examples:

-root-a_p is now pinned to file://${BASEDIR}/pinnes (a) (version dev)
+root-a_p is now pinned to file://${BASEDIR}/pinnes[a] (version dev)

-root-a-i_g is now pinned to git+file://${BASEDIR}/pinnes#master (a/i) (version dev)
+root-a-i_g is now pinned to git+file://${BASEDIR}/pinnes[a/i]#master (version dev)

-root-a_p.dev    rsync  file://${BASEDIR}/pinnes (a)
-root-b_g.dev    git    git+file://${BASEDIR}/pinnes#master (b)
+root-a_p.dev    rsync  file://${BASEDIR}/pinnes[a]
+root-b_g.dev    git    git+file://${BASEDIR}/pinnes[b]#master


--> retrieved root-a-i_g.dev  (git+file://${BASEDIR}/pinnes#master(a/i))
+-> retrieved root-a-i_g.dev  (git+file://${BASEDIR}/pinnes[a/i]#master)

-[root-a-i_g.l1] synchronised (git+file://${BASEDIR}/pinnes#master(a/i))
-[root-a-k_p.l1] synchronised (file://${BASEDIR}/pinnes(a/k))
+[root-a-i_g.l1] synchronised (git+file://${BASEDIR}/pinnes[a/i]#master)
+[root-a-k_p.l1] synchronised (file://${BASEDIR}/pinnes[a/k])

[dra27]

Could we even avoid the square brackets in the display?

[rjbou]

We need to differentiate the main url and the subpath. We can use another separator.

[dra27]

I was thinking we could kinda avoid it, but that would be inconsistent with opam pin add (i.e. unless we could make opam pin add git+https://github.com/dra27/package/subdir automatically infer the sub-directory, then I agree we need some kind of separator).

The problem is that the notation is opam specific, but perhaps we can therefore make it more explicit that there's a subpath pin involved. Possibility:

-root-a_p is now pinned to file://${BASEDIR}/pinnes (a) (version dev)
+root-a_p is now subpath-pinned to directory /a in file://${BASEDIR}/pinnes (version dev)

-root-a-i_g is now pinned to git+file://${BASEDIR}/pinnes#master (a/i) (version dev)
+root-a-i_g is now subpath-pinned to directory /a/i in git+file://${BASEDIR}/pinnes#master (version dev)

-root-a_p.dev    rsync  file://${BASEDIR}/pinnes (a)
-root-b_g.dev    git    git+file://${BASEDIR}/pinnes#master (b)
+root-a_p.dev    rsync  /a in file://${BASEDIR}/pinnes
+root-b_g.dev    git    /b in git+file://${BASEDIR}/pinnes#master


--> retrieved root-a-i_g.dev  (git+file://${BASEDIR}/pinnes#master(a/i))
+-> retrieved root-a-i_g.dev  (/a/i in git+file://${BASEDIR}/pinnes#master)

-[root-a-i_g.l1] synchronised (git+file://${BASEDIR}/pinnes#master(a/i))
-[root-a-k_p.l1] synchronised (file://${BASEDIR}/pinnes(a/k))
+[root-a-i_g.l1] synchronised (/a/i in git+file://${BASEDIR}/pinnes#master)
+[root-a-k_p.l1] synchronised (/a/k in file://${BASEDIR}/pinnes)

??

[rjbou]

I like the idea, but i'm wondering if these two examples are explicit for user. I give it a quick try:

[root-a_p.l2] synchronised (/a in file://${BASEDIR}/pinnes)

-> do we understand that a is a subpath?

+Ok, root-b_g is no longer subpath-pinned to /b in git+file://${BASEDIR}/pinnes#master (version l2)

-> it is not clear if it is the subpath-pinning that is removed or the pinning

[dra27]

Good point - perhaps:

[root-a_p.l2] synchronised (directory /a from file://${BASEDIR}/pinnes)

When un-pinning, perhaps there's no need for status at all - the fundamental change is that we've un-pinned that repo, so it could be the same message for both sub-path and normal?

[rjbou]

When un-pinning, perhaps there's no need for status at all - the fundamental change is that we've un-pinned that repo, so it could be the same message for both sub-path and normal?

It is possible, it will complicate API as in different function, it's `OpamPinCommand.string_of_pinned" that is called for printing.

[rjbou]

It's a local function :+1: