Scott proposed several steps to implement the new Quark system. I’ve seen several people agree with this proposal, and even if I’m not competent enough to tell if it’s good or bad, I trust him and will start working, slowly, on this.
One of the point is to :
- Define a new Quark 2.0 specification
- Adapt current Quarks (1.0) to the 2.0 specification
I suppose there will be a time where Quarks are still available as 1.0 while being also available as 2.0, so we can check if everything works, give users some time to switch from 1.0 to 2.0 (though I suppose a well done job shouldn’t impact users, but who knows yet), etc.
I’d say yes… and no.
Yes because what we intend to do is to move some of the current core functionalities inside Quarks so we don’t depend on them when a specific project does not depend on them. For example, QT. If your project is not using it’s GUI system, you should be able to run or share the project without QT being compiled or installed. Still, I think that QT is an important feature of the SuperCollider project. It allows to run the IDE, create Graphical Interfaces, and I see a lot of people using it. A QT Quark should definitely be well documented, OS compatible, tested, etc. Because even if it’s removed from the ‘technical core’, I think it will remain a ‘core feature’ of the SuperCollider project.
No because Quark is not only a developer tool, but also an user tool. Two examples :
A ‘beginner’ has a funny idea. It’s an artistic thing. Let’s say it’s a class that polls a UGen and draws shapes on a window based on the result of the poll. With this, you can easily have visual effects when you are livecoding. But the ‘beginner’ is not a ‘good’ developer, so his Quark doesn’t work on Linux, and he’s uncomfortable with writing documentation, so he didn’t do it. I don’t think those two reasons should prevent this user from distributing it’s work. I’d personally rather have people sharing bad code than not sharing at all.
Second example is that you can currently ‘hack’ the Quark system to use it as a project manager. I never did this, but I think some people on this forum could explain a bit more how they do it. Having to run tests or to write documentation would prevent this usage. But maybe this hack should be prohibited. Don’t know.
This adds complexity to the problem, because this ‘splits’ Quarks in two categories, that are difficult to distinguish (as you said, a machine can’t do that). But I think preserving user’s ability to create Quarks easily is fundamental.
First step is to take a look at how other projects do this, to get a better understanding of the problems, and the solutions :
- The semver format
- Python’s semver implementation
- NPM’s semver implementation
- How does PureData deal with dependencies ?
- How does Linux’s APT deal with dependies ?
- Other sources ?
Then we’re likely to develop a ‘Versioning Quark’, that should handle this automagically.
Then start implementing it into existing Quarks.
Then see how we use it to automatically compile the right versions of Classes.