On 13-06-27 06:34 PM, SiegeLord wrote:
On 06/27/2013 06:14 PM, Graydon Hoare wrote:
This does not mean that you must fetch a package named
"github.com/graydon/foo" from github.com, but it means that if you don't
have any other source for that package, you can guess at where to get
it. And it has a unique name (assuming you decide to use that fact).
I have a rust project hosted on github, but the package name is
certainly not github.com/<my_username>/<repository_name> in my mind.
That is what its pkgid would be, in the design we chose. It meets the
relevant criteria:
- decentralized
- collision-free
- "single string" package identification for use in 'extern mod'
- support for remote and local packages, overrides, redirects
What if it was hosted on bitbucket?
Then you would either:
- name it bitbucket.com/username/package
- (re)name it something else, via the redirect procedures below
What if I delete the repository?
Then either you will:
- redirect at server side[1]
- have downstream users override or redirect locally
- name it internally using an attribute, at the cost of losing the
ability for a user to fetch it remotely via pkgid
find it puzzling to have to place my local repository inside a directory
named github.com/<my_username>/<repository_name> for me to be able to
build my local copy using rustpkg.
It may be puzzling but it is both simple to explain and relatively
robust against misconfiguration. In any case, you only need to do that
if you expect to publish it. You can put it in a shorter named directory
-- any name you like -- if you don't expect to.
It's the last bit that bothers me the most: I can't build my local
project unless I introduce a completely irrelevant aspect (my git host
and username) into my metadata (the directory structure).
When we did it the other way, people were upset that they had to make a
separate file to hold metadata in, and they faced the difficulty of
having no simple unique names to refer to packages by when denoting a
dependency from one package to another or referring to a package on a
command line. This structure reuses a single form of relatively robust
structured identifiers for multiple roles (links in source code, remote
access protocols, filesystem organization). It is economical, which is
why we adopted it.
Most package system I've reviewed prior to writing that email used a
metadata file in its package system.
Which did you review, and which do you think we should imitate? Most
package systems I reviewed have numerous other failure modes:
- central index / namespace of all packages
- shallow, collision-prone global namespace
- poor to no integration with language module system
- poor to no integration with revision control
- weak or confusing support for mixing local overrides with remote
packages
It really is not clear why Rust must be nearly unique in this point.
We made it quite clear during design that we were copying seemingly-wise
and economical design choices from the Go package manager, and deviating
in places where they were weak (eg. versioning)
In the 3 sources of documentation
you've linked to there really wasn't a motivation behind why the
widespread metadata file approach was wrong.
I suppose not, though I'd hoped it was obvious reading through the
development threads. I hope I've outlined motives here well enough: that
this approach appears to be more-economical with names and number of
moving parts. Fewer layers of indirection, more reliance on constraints
from the outside world.
I understand that this is too late to change this, but at the same time
I find integrating my (sole for now) Rust project into rustpkg to be
really disruptive, relative to simply including a metadata file like
I've done for my projects in other languages.
It is late in the process. I'm sorry that it's disappointing to you but
to return to redesign at this point would mean shipping another whole
development cycle without a working package manager.
I realize the design may not be identical to other systems, but I
believe it's quite economical. We made it as simple as possible, so
there were as few ways to get things wrong as possible. All you need to
do is:
- rename the package directory to match its pkgid
- rename your crate entry points to {main,lib,test,bench}.rs
Is this really so disruptive? It's easy to explain and easy to get
right, hard to get wrong. At least that's the idea.
-Graydon
[1] if it helps, we are also planning to offer a
'pkg.rust-lang.org/user/foo' URL-redirection service, for people who
"don't trust code hosting URLs". This is _exactly as reliable_ a
mechanism as any other central-index thingy we might decide to operate.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
