Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
quarks (new) - dependencies specified with git url and refspec not working ? #1377
the help says
but using a git url with a refspec in the dependencies list (url@refspec) doesn't seem to work. I think the issue is that Quarks.new does not check for git urls like url@refspec like Quarks.load does:
here refspec is not extracted from name, if the name is of type url@refspec.
Btw, the new Quarks system rock !!!!
changed the title from
quarks (new) - dependencies specified with git url not working ?
quarks (new) - dependencies specified with git url and refspec not working ?
Mar 28, 2015
Apr 13, 2015
After looking at this in a little more detail - I wonder if the documentation should simply be changed? Supporting dependencies of the form "quark@refspec" AND "quark" -> "refspec" doesn't seem necessary, and opens the door to needless ambiguity (i.e. "email@example.com" -> "1.2"). The association form does everything we need just fine.
The only reason it supports quark -> version is for backward compatibility.
But it can only be written that way in supercollider code. Its an
So I figured the directory.txt should not use this arrow thingy, it should
And its natural to expect that if directory.txt allows @ then dependencies
Why have two separate ways of specifying a quark and its version ?
But I didn't even implement support for @ in the dependencies and didn't
-> is for backwards compatibility
until somebody actually decides to write both @ and -> then we shouldn't
So I will finish implementing @ in dependencies (and I found another bug in
and I will improve documentation to say that @ is the way to express it
and that -> is there for backwards compatibility
The bigger issue is that old quarks do not have tags, so we cannot check
We could at least tag each one with the version listed in its quark file.
On Mon, Apr 13, 2015 at 5:36 PM scztt firstname.lastname@example.org wrote:
Ah, didn't realize that -> was backwards only. Then this is right, apart from the bug regarding ref spec parsing. And if -> is effectively deprecated, then no need to protect people from using it incorrectly.
As per discussion here, the @ should already be split by the time we hit Quark.new - this should probably be done in Quarks:parseDependency.