Orbit - Package Manager - Specification/ideas

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:ivkrdj$ci4$1 at digitalmars.com...
> I've written a more formal specification of my ideas for a package manager 
> for D.
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>
> Note that I am exploring the possibility of using D as the language for 
> all the files mentioned in the link above.
>
> The current status is that building packages and installing them works, 
> but quite limited. No dependency tracking or central repository so far.
>
> Please comment and suggest.
>

Good start :)  Here are my random thoughts on it (sorry if you've already 
answered some of them, I haven't read the rest of this thread yet):

- I find the "orb" vs "orbit" distinction a little confusing and 
unnecessary. Why not just call it all "orb"? (Or call everything "orbit"?)

- I think the files "orbfile", "{name}.orbspec" and "metadata" (the one 
inside the packages) should all just be one file. Frankly, the existence of 
all three of them confuses the hell out of me.

- Are the subtypes a "pick one" or "pick all that are included" deal? I 
think that latter would make more sense.

- Instead of "~> 0.3.4", what about "> 0.3+.4+"? Or ""~> 0.3+.4+"? Or 
something vaguely like that. That would be more flexible.

- What happens if someone tries to upload a newer version with the same old 
version number? Or if they forcefully do it?

- Are version numbers allowed to have more or less than three parts? I think 
they should. Do version comparisons still work on version numbers with an 
arbitrary number of parts? Again, I think they should.

- Is version "2.10" after "2.1" or are they the same? What about "2.01" vs 
"2.1"? I would vote for "2.10 > 2.1 == 2.01", because I see version "parts" 
as distinct numbers separated by a period, rather than fractional numbers.

- It should allow boolean operators and parens for the version selections. 
For instance: "(>= 2.1 && <= 2.6 && != 2.4) || >= 3.4" (Ie, "Any version 
from 2.1 through 2.6, but 2.4 has critical bugs, and 3.4+ contains a 2.x 
compatibility layer.")

- There should be a "list" command and a "list {package name}" command to 
see what's installed. Maybe even "list {package name} {version expression}"? 
And maybe something too see what's available but not yet installed? They 
should all list the versions in guaranteed-sorted order so you can see which 
are the newest and oldest installed versions by looking at the first and 
last.

- At some point, 7z should be supported (and tarballs, of course).

- How should platforms be handled WRT packages? Ie, Do all platforms need to 
be in the same orb package? Do they all need to be in separate packages? 
Either way? If they're not all required to be in the same package, how does 
orb find the package that had the right platform?

- Is it really necessary to have separate "build_dependencies" and 
"runtime_dependencies"? And why have both "runtime_dependencies" and "orbs" 
instead of just picking one name and sticking with it?

- Would it be a good idea to have and additional field "extra" for 
non-standard expandability? So people could add extra fields they felt would 
be useful, like "extra.foo" and "extra.bar", etc. And popular ones could 
eventually be formally added to the specification as just simply "foo" and 
"bar".

- What's the point of the fields "files", "libraries" and "executables"? 
Seems like extra work for no real benefit.

- This supports having multiple versions of the same package installed at 
the same time, right? If not it should.

- I see there's an "upgrade" callback, but I didn't see an "upgrade" 
command. Is upgrading in or out? I think that there should be an "upgrade" 
command that upgrades the installed versions of packages as far as it can 
*without* breaking any other installed packages that depend on it. Ex, if 
Foo requires Bar v2.6 or earlier, and SuperFoo requires Bar v2.7 or earlier, 
and Bar v2.3 is installed, but the latest Bar is v2.9, then "upgrade bar" 
would upgrade Bar v2.3 to v2.6 and display a message that says "Bar upgraded 
from 2.3 to 2.6, but the newest is 2.9, run "orb install Bar" to install the 
newest Bar, too." (Or maybe it should install both 2.6 and 2.7? Or one/both 
of those and 2.9?) For upgrading, we should also think about how to do 
upgrades without clobbering any of it's settings.

- For POSTing a package to a repository, how does authentication work? All 
repos don't have to provide unrestricted upload access do they?

- I'm not sure I understand how the "source" command works. Can it be 
provided more than once? And then it just picks the first one that actually 
has the package?

- The "central repositories" don't necessarily sound all that central, so 
they probably should just be called "repositories".

- What about default repositories? It should support that. (Kinda makes 
sense, otherwise how would "orb install xxx" know where to look?) And there 
should be simple commands to add/update/remove/list (and reorder?) the 
default repositories. If a package A specifies a dependency B and a 
repository for that dependency B, then which one has priority for 
downloading B: The default repositories or the repository specified by 
package A?

- Here's a problem with using an actual programming language for the 
orbfile/name.orbspec/metadata file: Suppose Orb version X uses Ruby version 
Y. Then, Orb X+1 comes out and which has Ruby upgraded to Y+1. Now, someone 
creates PackageA with an orbfile/name.orbspec/whatever that relies on Ruby 
Y+1. Someone else still has Orb version X and tries to get PackageA. Kaboom!

Therefore, the orbfile/name.orbspec/whatever needs to specify which version 
of Orb (or Ruby) it requires. But now we have a chicken-and-the-egg problem: 
How can Orb X figure out that PackageA requires Orb X+1 if Orb X can't 
properly read PackageA's orbfile/name.orbspec/whatever?

- If I install D library "libfoo", then I should be able write myapp.d with 
"include foo.blah;" and then do "dmd myapp.d" *without* manually 
specifying -Ipath_to_libfoo. It should just work. How will Orb handle that? 
And how will that interact with DVM? Ie, if I do "dvm use 2.051", then "orb 
install libfoo", then "dvm use 2.054", then I should still have access to 
libfoo without needing to specify -Ipath_to_libfoo.

- Where does everything get installed?

- In many ways this sounds a lot like a generalized DVM. Maybe Orb should 
eventually take over DVM's duties by making a DMD orb package.