ArtifactIDs, GroupIDs etc

[johnwalker]

Do we want to go the maven way? Should we rethink the way we qualify project names since we aren't on java?

[heyLu]

Not sure, for now package names are just <username>/<repo-name> to be able to fetch things from GitHub. It's inspired by go get (with versioning, though), but doesn't support other providers and paths in a repo yet.

I'd like to support other providers (BitBucket, tarballs/zip files, local file system) in the future, but didn't want to implement them yet because there was no need for them so far.

Can you describe what you mean by "the maven way"? Do you have any ideas or suggestions you'd prefer?

[halgari]

I've been a fan of go get for some time. Minus the fact that they seem to always pull from HEAD. So if we allow versioning, I'm all for ditching the artifact/groupid stuff.

[heyLu]

I'm still not sure where we use artifact/groupid somewhere. We have to use something to fetch libraries from GitHub, so that's why it's heyLu/hiccup.pxi. Strings are an alternative, but I prefer this syntax.

Just for clarity: a dependency is currently a vector: [<username>/<reponame> "<git-ref>"]. This allows fetching from GitHub with very precise versioning (any git ref is allowed, e.g. tags, branches, commits, ...).

It is a bit confusing that the namespaces of a package are independent of the dependency specifier, e.g. heyLu/hiccup.pxi provides hiccup.* availlable. But I think this tradeoff is ok, because this makes switching to different versions of a package (for example a fork) without having to change all the imports.

[johnwalker]

I am also very much in favor of golang's approach. Not that we're using artifact id's currently.

So, for example - if hiccup.core were written in golang, it would be:

package hiccup

...

and this file would be located at github.com/heyLu/hiccup/core.go.

Should we do the same in pixie?

(ns hiccup.core ...)

could also be located at $PIXIEPATH/src/github.com/heyLu/hiccup/core.pxi. This approach involves the tradeoff that heyLu mentioned.

(defproject cohen "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [["github.com/heyLu/hiccup" "0.1.0-alpha"]])

And then usage:

(ns cohen.core
  (:import hiccup.core))

The biggest issue is that ns declarations include information that we can infer from paths and filenames. I think this approach is alright after a few improvements. Having the namespace encoded in the filename means that viewing a lisp program as a stream of forms wouldn't be as meaningful in pixie, though.

[heyLu]

I don't really like that part of the go get approach. (E.g. the global GOPATH and having to put everything under it.) The thing I wanted to copy was fetching dependencies from GitHub, plus the ability to precisely specify what to import.

I think the current approach works well enough, e.g. fetch all dependencies into ./deps and just set up load-paths so that pixie finds the libraries. How the namespaces are laid out is up to library authors.

We could recommend that people use matching namespace and repo names, but I wouldn't require it.

[johnwalker]

I'm totally on board with everything @heyLu said.