rename "language"

[hackergrrl]

The big appeal of gx to me is its agnostic nature: it provides package management and versioned dependencies happily and blindly.

"language" makes a deep assumption: that you're writing a package manager for a programming language. Why not "ecosystem" or "namespace"? gx doesn't know about semantics (rightly): there could be ten different and equally valid packaging styles for Java -- but only one lucky developer wins that language namespace.

Let's keep gx beautifully ignorant: blindly support all ecosystems!

[whyrusleeping]

hrm... good point, but i'm not a huge fan of either ecosystem or namespace... 'packageType' is closer to what i'm thinking...

[whyrusleeping]

somewhat related, referring to the language field as $FIELD for now, whatever its value is will also have an extra object, where the 'key' is the value of $FIELD. for example, go packages will have:

{
  "go" : {
    "dvcsimport":"github.com/ipfs/go-log",
    "goversion":"1.5.1",
  }
}

this lets you define extra metadata to be understood by the surrounding tooling.

[hackergrrl]

I think you're right: a package could be part of multiple ecosystems but still be semantically compatible across them. :+1:

Having $FIELD be a key->object mapping makes a lot of sense: package format-specific values without cluttering the global package.json namespace. I like this a lot more than a notion of packageType: with the package type being a key, now it can be a member of many intersecting formats!

[whyrusleeping]

we still need the packageType/$FIELD to tell gx where to look for this extra info.

[whyrusleeping]

honestly, it could be an array of things.

[whyrusleeping]

or something like:

{
  $FIELD: {
    "go": {
  ......
    }
  }
}

[hackergrrl]

Why does gx need to know about this value at all? IPFS provides a unique global content-addressed namespace -- why does gx care? I'm thinking the ecosystem-specific tooling is the only one that'll need to know about a go or python or java field.

[whyrusleeping]

right, but the UX i want is for gx to be able to make calls to the other specific tooling automatically, on behalf of the user. It needs some sort of context to know what calls to try and make.

[hackergrrl]

It sounded like, as per #15, that the goal was to keep gx ecosystem agnostic, and rely on downstream users to create language-specific tooling. This seems like the route of fewest assumptions, since gx can never possibly hope to implement packaging for every possible language or use case the userbase might conceive of.

e.g. I write a Python package manager -- ppm? -- that uses libgx for package retrieval, dependency resolution, etc. This way gx just needs to do its base job well and downstream users can reap the benefits.

[whyrusleeping]

yeah... i guess i have slightly different thoughts. I'm currently aiming for a gitlike extensibility. For language=go, we call out to a tool like gx.go, for things like gx.go post-import <args>

[hackergrrl]

Understood and agreed: let's go the git road for integration. :+1:

Re storing language/ecosystem/environment/whatever in package.json, do you then see users using the gx tool directly to invoke env-specific commands? e.g.

$ gx build

# does this look up the env name in package.json and call `gx-[env-name] build` when
# it sees 'build' isn't a command it knows?

[whyrusleeping]

Yeah, i think that makes the most sense. That way, users of gx can really install and build any package they want easily. Without having to learn all of the intricacies of whatever language the package is in.