Changing Package Metadata

[robfallows]

Continuing the discussion from Request for feedback: Split meteor-platform into smaller umbrella packages:

Request for feedback: Split meteor-platform into smaller umbrella packages

Right now, we have a large meta-package called meteor-platform which contains a lot of neat packages that people might want when building their app. Unfortunately, since everything is in one package, it’s hard to remove parts that you want to replace - you need to remove the platform meta-package and add in each package separately. In particular, if you want to avoid using Blaze for HTML templates, it’s very difficult.

I think there will be a lot of benefits from splitting up the meteor-platform package into smaller packages that contain units of functionality.

See the full plan and leave comments on GitHub: https://github.com/meteor/meteor/pull/4851

This particular topic feeds off the GitHub page which @sashko linked to. In one of his comments @sashko says:

@AndreasGalster @timbrandin I think you both have some good ideas about ways to improve meteor list - maybe we should start a forum thread about it or something?

So, even though I am neither @AndreasGalster nor @timbrandin , I thought I’d raise it here!

In order to drive improvements to meteor list my belief is that we need to add to the metadata of packages (presumably with appropriate content in package.js). Any such changes would also be useful on atmosphere and within meteor search.

So, this topic is a place to collate a community wishlist: What would you like to see in meteor list and what might need to be in place in package.js to drive that?

[robfallows]

I’ll kick the ball off with a cross-post from here: Cross-OS Package Friction to mitigate the lack of visibility of a package working on a particular OS:

At the moment I’m thinking of something along the lines of an optional package.js stanza with whitelisted properties having boolean true or false (or 1 or 0) values. A missing property would mean the compatibility is unknown:

serverPlatforms: {
  Windows: false, // Does NOT work on Windows
  Linux: true // Does work on Linux
} // There is no OSX property, so we don't know if it works on that

The onus is on the individual developer to do the tests and be honest. I had thought of a number of ways to make this significantly more complicated, but for an initial foray this seems sufficient. The object would be made available through the existing MDG Package API.

The three main server OS’s (Linux, Windows, OSX) would form the whitelisted properties. It does mean that if a developer gets a package working on AIX or z/OS I can’t indicate that, but I suspect they will be very rare, specialised cases.