Is there an HTTP API for Atmosphere so we can use curl/wget/etc to download packages? For example, I’d like to download https://atmospherejs.com/vasaka/livescript-compiler to see what’s in it (it has no GitHub link).
You cannot download the source code, but the downloaded packages end up in ~/.meteor/packages/ anyway so you can take a peek in the built-form there.
Aaah, okay. That turns out to be my problem. I was hoping to rely on knowing information about the current application in order to build a package, but when publishing packages there’s no way to know what application the package will be used in. I thought perhaps the packages came in their source form, then were built for the application they were in (different things need to happen with my package’s build depending on what the application has in it). It was all working perfectly when testing packages locally of course.
… just a thought: Initially your package could still be useful to a (more limited) number of people who’re willing to pull in your package directly by cloning from GH / adding as submodule. But of course that doesn’t solve the problem for making things work from/with Atmosphere.
Another thought: Well, some (most?) packages have a GH repository URL in their package information. I suppose that would be one way to get the package source… (while still not solving the other issue in the previous paragraph.)
What specific information are you seeking to query in an app?
There is a discussion over here: https://github.com/lb-/moment-helpers/issues/15#issuecomment-102007993 regarding how a package might be able to find out about existing packages by querying its name.
I thought of that, which would work, but I do really want to make it compatible with Atmosphere, which will take even more work it turns out. Rolling up my sleeves now! 
For sure, the goal always has to be to make it available for everyone in the standard, easiest way to include it! Kudos for going at it! I’ll be watching and if I can see something I can help with I will!
1 Like
I want to determine which packages are installed in an app, and which of those packages depend on rocket:module. I’ve been able to do it, and there are some nice helper methods in sanjo:meteor-files-helpers, but the real issue is that it’s impossible to use these helpers in a build plugin for a package being published to Atmosphere, because there’s no way to tell what application the package will run in when building it standalone instead of locally in an existing package.
Just a few more thoughts, not sure if it helps…
First idea now was: Can’t you just put something, anything, in the compiled version of every package that is using your rocket:module package so that you could see that it is there and whatever info you need from just the compiled output? Since you do have some level of control over what your package changes in the output of a meteor package build, then in theory you should be able to put any information you want into the product. Makes sense? (How that translates practically I’ll leave to your imagination for now.)
And then… what you’re describing what you’re wanting to do sounds like… it sounds like something that requires more than just build-time work to be done. It sounds more like what is supposed to happen at runtime cannot be determined at build-time. Well, “build-time” of the final app – yes, then it’s determined. But build-time of a package that can again be depended upon and that will be thrown into a pool of unknown other packages – nope, no way to know until the actual app is being built.
So my understanding is that for packages your package should just not actually add anything to the output (which means not state anything that should be sent to the client), and only declare dependencies, basically (what this package requires that should be sent to the client), and then at runtime or app-build-time you take all those dependencies and merge/solve them and only then let Meteor know what it needs to send.
That does sound like this would require you to be able to prevent packages from saying api.addFile(... 'client'), but maybe it just means that when a package in the future decides to adopt rocket:module it will just remove all those calls and handle all client-side requires / dependency declarations purely through rocket:module which from now on takes care of the api.addFiles(... 'client') part.
Not sure if and how all that makes sense and how well I’ve even understood what you’re intending to do in detail. But if there’s something in there that provides at least one new idea or insight or impulse, then my mission were accomplished either way 
@seeekr Good ideas!! I was thinking similarly to that.
It would be great if a build plugin could be specified to run during “app-build-time”, but I don’t think that’s possible, and it would go against Meteor’s “reproducible build” design.
Perhaps in rocket:module’s build plugin I can do something like put a placeholder in all the files that are added with api.addFiles during the standalone package build for publishing to Atmosphere, something like
/****ROCKET:MODULE:<package-name-here>****/
then at runtime (but somehow before it is all sent to the client which is what I’m not sure how to do yet) replace the placeholders with the bundle codes.
You could ask package authors to export a specific static variable from their packages if they depend on your package and it would allow you to query those variables to get what you want.
Would not be automatic, but perfectly acceptable.
That’s true, but the source code for those packages would need to run in order for the symbol to be exported, and the code for those packages needs to be compiled by rocket:module (inception? 
). So rocket:module needs to know about the packages before their code can run in order to compile their bundles in the first place.
What about exporting the symbols in a file that isn’t compiled by rocket:module? That would be possible, but in that case the tricky thing would be executing compiled code of a package at the right time so that api.exports can be accessed by packages that depend on said package.
The only way I see tackling this is somehow hooking into the compile steps during app-build-time so that the final built files can be sent to the client/server to finally execute with all code in place.
Also, mrt packages have homepage field which is not displayed in the Atmosphere, but it it is often GitHub URL. Use meteor show --ejson mrt:package to see it.
1 Like