Orbit - Package Manager - Specification/ideas

Jacob Carlborg doob at me.com
Tue Jul 19 01:23:01 PDT 2011


On 2011-07-19 03:58, Nick Sabalausky wrote:
> What about "orb"/"orblib", or "orbit"/"liborbit", etc? Be easier to tell
> which is which that way anyway.

Yeah, that would be one option. You can also see like this: "Hey, I have 
a compiler, it's named 'GNU C Compiler', it's invoked with the 'gcc' 
command". What's the confusion with that?

> Ok, I see. That makes sense.

Ok, good.

>> Is it a good idea to take the name directory where the orbspec is located?
>>
>
> No, I don't think it is. When orb downloads/installs a package it should
> definitely put it in a directory named the same as the package. But I often
> have reason to projects in a directory with a (slightly) different name from
> the project, so I don't think they should be expected to be the same names a
> packages the user is developing.
>
> So I'm fine with the orbspec filename being prepended with the package
> name...Only one minor potential issue I see: What happens if a single
> project has both "foo.orbspec" and "bar.orbspec"?

When building the package? You just run "orb build foo" or "or build 
bar". Were you hoping for only "orb build"? In that case I guess it 
would be possible if there's only one .orbspec in the current directory. 
That know if that's confusing.

> Sorry, can you be more specific on what you mean by that?

The syntax you suggested. Instead of having "~> 0.3.4" then you could 
have "~> 0.3.4+" or "~> 0.3+.4+".

> True, so I guess there should be a way to do platform-specific packages.

Don't know how much of an issue this is in reality. Although there could 
be fairly large libraries and applications. I know DWT is quite large.

> Suppose there's a (possibly default) repository:
>
> http://www.super-d-repos.com/joesmith/
>
> And the user runs:
>
> $ orb install foo 1.2.3
>
> What url does orb try to retreive?:
>
> http://www.super-d-repos.com/joesmith/foo-1.2.3.zip
> http://www.super-d-repos.com/joesmith/linux/foo-1.2.3.zip
> http://www.super-d-repos.com/joesmith/multiplatform/foo-1.2.3.zip

I guess that just needs to be standardized.

> Etc...
>
> We'd need to have some well-designed standard for how that works.
>
> I'm not sure we should require the repo actually be specified as:
>
> http://www.super-d-repos.com/joesmith/linux/
>
> Because that would be platform-dependent and require extra platform-handling
> code for the orbspec author. And it would be different for different repos.
> Come to think of it, the same issue applies to making the platform part of
> the package name. So maybe a good path-based system would be better.

How would it require extra platform-handling for the orbspec author? All 
repositories behave in the same way, if not, it's not an orb repository.

> This makes me think of another question: Once different comression formats
> are allowed, if someone uses orb to download/install a package, how does orb
> know whether to grab a .zip, or a .bz2, or a .7z, etc?

I guees it's same as with the platform. Just standardize on a specific 
order. i.e. 7z, then bz2 and last zip.

> If, for example, the author wants the windows package to be separate because
> it (hypothetically) has a lot of differences from posix, but the different
> posix versions are very similar so may as well be in the same package.

That is for a source package?

> Good point. Although, of course, that only applies to binary packages. So
> yea, it seems that both multi-platform and platform-specific packages should
> be supported. And there needs to be some system for dealing with that.

There is way more to think about than one actually want to recognize :)


> This is another thing I'm unclear on, the nature of "installing". It almost
> sounds like you're saying that all the files in the package other than
> "libraries" and "executables" are just not used for anything and just thrown
> away. I doubt that's it though.

If you but "main.d" and "main.exe" in the "files" field. And you have 
"main.exe" in the "executables" field it, will only install "main.exe". 
There is no point in installing "main.d" as well, you actually don't 
need to put in the package in the first place. But there could be an 
option to install the source code as well, if present.

> Is this how you're envisioning it?:
>
> 1. User says "orb install foo".
>
> 2. Orb downloads and extracts the foo package to a temp directory.
>
> 3. Orb invokes the build process to build foo (BTW, how is that "how to
> build" commandline string  specified in the orbspec? The closest thing I see
> is the "build" field, but it looks like that's just the name of the tool
> used. An actual command line string is going to be needed.)
>
> 4. Orb copies the files listed in "libraries" and "executables" from the
> temp dir to their permanent location.
>
> 5. Temp dir is cleared.

Something like that.

> If so, how do you account for non-compiled source-based libraries? Include
> the *.d files in "libraries"?

That's a good question. Maybe the "type" field needs to include "source".

> Hmm, I guess "files" isn't so bad.

Oh, and Dake does this with the help of Orbit. It's acutally Orbit that 
generates the orbspec but Dake passes all information about the orbspec 
to Orbit.

> I think it'd be nicer if invoking a process wasn't needed for that.
> (Although it could just be done in the "configure" step, but it'd be nicer
> if orb could just handle it without the buildscript needing to worry about
> it.)

It doesn't technically needs to create a process and invoke the orb 
command. Dake can just like with liborbit and take the information it needs.

Every tool should be built as a library and a thin wrapper on top of 
that for the executable. Makes everything easier :).

> What about projects that don't use "{project_root}" as the include
> directory? My projects, for instance, typically use "{project_root}/src".

Hmm, that's a good question. Wonder how other tools handle this.

> The same thing as if you manually did:
>
> $ dvm use 2.054
> $ rdmd -I~/proj/foo-1.2.3/includes myApp.d
>
> It just won't work.

Once you have installed the packages for the new compiler you can use 
dvm as before.


> What about "orb use" on binary packages?

I don't follow.

> What I'm saying is that maybe they shouldn't be so different.

As far as I know dvm HAS to work as it does. And I'm certainly don't 
arbitrary packages manipulating the PATH, registry and the shell start 
up file.

> I don't believe that the current compiler *should* decide what packages are
> available/installed. Maybe there could be some optional magic to warn when
> using a compiler/package combination that isn't known to work. But aside
> from that, I really think these should be orthogonal.

Ok, one option would be to have all packages installed globally in DVM, 
i.e. available for all compilers. DVM could let you create orb sets and 
switch between them. Then you could have one orb set for each compiler 
if you wanted. Example:

$ dvm use 2.053
$ orb list

Installed packages:
foo
bar

$ dvm install 2.054
$ dvm use 2.054
$ orb list

Installed packages:
foo
bar

$ dvm orbset create test
$ dvm orbset use test
$ orb list

No installed packages

Now, when installing a new package it will only be installed to the 
"test" orb set. How those this sound?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list