Is there a way to perform build operations after installing a packages. That would be very helpful. When making my package rocket:module, I was working with local packages, so it was easy to get information about the current application, and that would affect the outcome of the build result (certain things existing in the application were criteria for build steps).
But now that I’ve tried to publish, I’ve realized that it’s impossible to build packages the way I want, on a per-application basis, because the published packages have to be completely built before publishing.
It’d be nice if there were some way to flag some source code to be handled on post install, so that it’d be possible to build the source in certain ways depending on what it detected in the application.
Is something like this possible? Maybe I just have to write some runtime server-side code for what I want to do instead of using a build plugin like I am currently doing?
Package.registerBuildPlugin is pre-install, so if I’ve registered a build plugin, that plugin will run before publishing to Atmosphere, so I can’t detect certain feature of the application that the plugin will run in. I was originally developing locally, so that made it easy to detect application features in the filesystem in the build plugin, but I’ve now moved out of local.
Indeed meteor-files-helpers has been helpful, but I have the problem that the helpers aren’t useful during standalone build of a package because the build plugin that runs has no reference application in the filesystem. It all works perfect when developing with local packages.
@Sanjo@serkandurusoy For example, if I write a package called trusktr:foo in a standalone place not in a local package, and trusktr:foo depends on rocket:module, and rocket:module has a build plugin that depends on knowing the path of the current application, then trusktr:foo fails to build because it’s not inside of any application.
@serkandurusoy I’ll definitely check those packages out. Thanks!! Relative paths don’t work because ultimately I have to look in the app for currently installed packages, relative or not, so the info simply isn’t available for non-local package builds.
@serkandurusoy Aha! So build plugin source handlers also work for application files, which I haven’t actually tested yet; it seems like the simpler case compared to package files. I see in those build plugins that they don’t gather any app-specific info at all, so they will work just fine during publish-build-time and app-build-time alike. They are completely app-agnostic, while rocket:module needs to discover what packages in an app depend on rocket:module.
My issue was accessing the version of a package in a deployed app, as far as I know it’s not possible. I just pinged @dgreensp about it, maybe he’ll have some input on this?
@serkandurusoy@sacha@dgreensp I’m not sure if I need that in my case, but that would be interesting to know! It might be a nice feature for apps that want to display version info about themselves, and could be useful for users filing bug reports through the app, etc.
