More detailed package information during runtime.

[robertpitt]

The issue

Currently within meteor we have very little information regarding packages (at runtime), the only place to find out your versions are either in the .meteor/versions file, the meteor list command, and the Package namespace.

The first two options are only available at the users will, the third operation allows packages (during runtime) to see what else they have hooked into the project.

The problem with the third option is that the only piece of information available is the package names, and although that suffices most of the time, I believe that having more information will help packages work together a little more seamlessly.

• Package Name
• Package Version *
• Package Dependencies
• Package Description.

We see many packages doing things like if('meteorhacks:flow-router' in Package) and if('autopublish' in Package)

I don't feel like this is good enough and I think that the core should provide a better interface for packages.

I have managed to come up with a clever / hackish way in order to compile the versions file at runtime in order to allow for version and package checking but obviously this would be better suited at the core.

See my package for a solution to gaining version numbers during runtime: https://github.com/meteor-atomic/packages

Questions:

1. Is it possible to look at better package interface during runtime, build and compile time
2. it would also be helpful if package information was available within the package.onUse method so we can load either bootstrap templates, semantic templates or pragmatically change dependencies.

Thoughts?

[stubailo]

@robertpitt what is the use case for package dependencies or description? I think this would be a valuable feature but we should have a good handle on the use cases for all of the data provided.

Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub.

[robertpitt]

My personal use case is for experimenting with administration panel that shows the user of our application what modules are installed and what they do, there version and place to report bugs.

One of my projects is a blog, and I am experimenting with a separate, isolated administration application that runs independent of the blog (not bundled together), so one administration can control many blogs by switching the DDP connection sources on the admin to the remote blog.

This brings up remote management, stop/restart/starting a remote blog, remotely adding packages and deploying bundles etc.

Apart from those two personal reasons, I think packages will be able to self-tune to it's environment which could be a ++ in package development.

regards

[Slava]

meteor show package@version is the command that shows the detailed information about a particular package.

[robertpitt]

Sorry @Slava for not clarifying that information is only available to a developer, packages during runtime cannot get any more information apart from the package name.

[Slava]

I don't see any good reason for having this information available in the run-time. This is still can be marked as a "feature request", but I honestly think you are better off spawning a separate process that has access to the metadata over the official interfaces. https://github.com/meteor/meteor/wiki/Meteor-Package-Server-API

[robertpitt]

Even if we spawned a seperate thread to lookup the metadata.

1. I would have to download the entire catalogue in order to view the package information
2. I still would not be able to identify the current version installed.

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!