New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow smart packages to be loaded with custom options #1292

Closed
mizzao opened this Issue Aug 8, 2013 · 10 comments

Comments

Projects
None yet
5 participants
@mizzao
Copy link
Contributor

mizzao commented Aug 8, 2013

As of right now, smart packages aren't very smart. In fact, they're kind of dumb. You either use one, or you don't. There are very few ways to configure how a smart package is pulled in.

I propose extending the package API to the following. First, each package would take a custom options hash This hash would be exported to be available in package code as Package.options or something like that, and also be available to the package.js function:

Package.on_use(function (api, where, options) {
  if( options.something === "foo" ) {
    api.add_files('option_foo.coffee');
  }
  else if( options.something === "bar" ) {
    api.add_files('option_bar.coffee');
  }
});

and in code for the package itself:

if( Package.options.something === 'foo' ) {
  ...
}

A package using this package would now be able to specify a custom options argument:

 api.use('some-package', 'server', { something: "foo"} );

In the top-level app, the .meteor/packages file would now have something similar to what @tmeasday uses in his smart.json for meteorite, instead of just being single lines:

{
  "packages": {
    "standard-app-packages": {},
    "some-package": {
      "version": "0.1.0",
      "options": { "something": "foo" }
    }
  }
}

At the same time, I would recommend exposing app settings to the package API as mentioned in #180, perhaps in like Package.globals or something. There are many instances where these would be useful, but here are a few examples:

  • Being able to configure a smart package with different settings such as a database, API keys, and stuff like that.
  • Allowing a smart package to take on different roles in different apps when the codebase is similar
  • Having a common interface for smart package settings instead of all in Meteor.settings or other random places (/private).
  • In packages such as my https://github.com/mizzao/meteor-sharejs where we may not want to send all files in the bundle to the client but only certain ones for specific settings

Other references:

  • In #1259 @glasser mentioned better support for using npm as a way to distribute files in smart packages. This is a potential way to do that.
  • In #1291 this would give the ability to turn off local storage in certain useful instances.

Caveats:

  • There would need to be some conflict resolution if a given package is loaded from different dependencies with different settings

Would you guys take a PR against devel for this, or is something in the works?

@andreioprisan

This comment has been minimized.

Copy link

andreioprisan commented Aug 15, 2013

+1

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Sep 24, 2013

Any updates or comments from the core team on this?

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Sep 27, 2013

Just watched Devshop 8 and hope you guys will take into account how to pass options to packages and allow control flow in file loading and dependencies as this moves toward 1.0 (even if we're no longer using @gschmidt's 2-hour hacked package API :)

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Apr 22, 2014

Consult this thread for continuing discussion.

Closing as I sense @glasser is about to drop the hammer on this soon.

@mizzao mizzao closed this Apr 22, 2014

@speigg

This comment has been minimized.

Copy link

speigg commented Jul 23, 2014

Is this possible yet?

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Jul 23, 2014

@speigg I think the best way to discuss this issue is by commenting at https://meteor.hackpad.com/Getting-Started-With-Unipackage-IOckQBQgXaQ.

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Oct 2, 2014

I'd like to bring this up again as we approach 1.0. Would it be possible to support loading packages with options, and for the api.onUse function to be able to access these options?

The current system is somewhat constrained in that all package logic at the meta-level happens at publish/build time rather than at run time. Can we make a way for packages to dynamically determine what files are served and what assets are added, rather than completely statically?

@mizzao mizzao reopened this Oct 2, 2014

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Oct 2, 2014

Sorry, didn't mean to sound insensitive about this. By referring to 1.0 I just meant in hoping not to have the current features set in stone.

If this is a reasonable issue, I'm happy to leave it on the table for now and revisit it later.

@alanning

This comment has been minimized.

Copy link
Contributor

alanning commented Oct 13, 2014

@rbabayoff suggests that it may be possible to implement this using the new "publish-release" functionality in 0.9.3+: http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/

@glasser

This comment has been minimized.

Copy link
Member

glasser commented Oct 21, 2014

This feature request is being tracked on the roadmap:

https://trello.com/c/mHK2dpr5/68-new-way-of-defining-packages-and-controlling-file-load-order

You can see some thoughts on configuration in our current tentative design doc:

https://meteor.hackpad.com/New-control-file-brainstorming-ZDBMiEQ6DZl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment