{"action":"created","issue":{"url":"https://api.github.com/repos/jaws-framework/JAWS/issues/167","labels_url":"https://api.github.com/repos/jaws-framework/JAWS/issues/167/labels{/name}","comments_url":"https://api.github.com/repos/jaws-framework/JAWS/issues/167/comments","events_url":"https://api.github.com/repos/jaws-framework/JAWS/issues/167/events","html_url":"https://github.com/jaws-framework/JAWS/issues/167","id":108528724,"number":167,"title":"Dependency management needed?","user":{"login":"joostfarla","id":851863,"avatar_url":"https://avatars.githubusercontent.com/u/851863?v=3","gravatar_id":"","url":"https://api.github.com/users/joostfarla","html_url":"https://github.com/joostfarla","followers_url":"https://api.github.com/users/joostfarla/followers","following_url":"https://api.github.com/users/joostfarla/following{/other_user}","gists_url":"https://api.github.com/users/joostfarla/gists{/gist_id}","starred_url":"https://api.github.com/users/joostfarla/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joostfarla/subscriptions","organizations_url":"https://api.github.com/users/joostfarla/orgs","repos_url":"https://api.github.com/users/joostfarla/repos","events_url":"https://api.github.com/users/joostfarla/events{/privacy}","received_events_url":"https://api.github.com/users/joostfarla/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":24,"created_at":"2015-09-27T10:45:21Z","updated_at":"2015-09-29T06:46:15Z","closed_at":null,"body":"Great to see new modules popping up every day. This is really exciting!\r\n\r\nFor the JAWS ecosystem to be able to grow and stabilize, we need to think about how to handle dependencies. The current module implementation is very basic and does not take versioning and underlying dependencies into account (see: https://github.com/jaws-framework/JAWS/issues/148).\r\n\r\nThings we have to start debating about:\r\n\r\n* Do we need to store dependency configuration in the project (jaws.json) and module (awsm.json) configurations? I think we do, because:\r\n  * ideally you want to keep vendor packages out of version control. We could implement a script which walks through the dependency graph and installs any missing dependencies and upgrades versions where needed/possible. This is crucial when working in development teams.\r\n  * otherwise there’s no place where you can define underlying dependencies including compatible versions or version ranges.\r\n\r\n* How to handle underlying AWSM dependencies, i.e. module X requires module Y, which requires module Z? This would definitely stimulate creating small components focused on one specific task. I would suggest flattening the dependency graph (i.e. store all modules on the same directory level) to keep things simple for other tasks like deployments. Taking the recursive approach (like NPM does) would make things too complex. Downside (or is this maybe an upside?) of this approach is that you cannot have multiple versions of the same AWSM module in your project which could cause dependency conflicts.\r\n\r\n* Is the current project structure suitable for this? I would suggest splitting vendor packages from your application code/modules. Otherwise it’s too hard to do verification on which modules should be (un-)installed. Moreover I find it more clean to separate these.\r\n\r\n* Do we need to support pre/post install-scripts for any custom checks or build steps a module needs. At this moment the installer checks for the presence of a package.json file and runs npm install. This could be made more generic (especially for non-node modules in the future).\r\n\r\nI’m having tons of other considerations, but I guess we have to agree on the basics first.\r\n\r\nLooking forward to your thoughts! I would be happy to start implementing this once we agree on the implementation."},"comment":{"url":"https://api.github.com/repos/jaws-framework/JAWS/issues/comments/143961327","html_url":"https://github.com/jaws-framework/JAWS/issues/167#issuecomment-143961327","issue_url":"https://api.github.com/repos/jaws-framework/JAWS/issues/167","id":143961327,"user":{"login":"joostfarla","id":851863,"avatar_url":"https://avatars.githubusercontent.com/u/851863?v=3","gravatar_id":"","url":"https://api.github.com/users/joostfarla","html_url":"https://github.com/joostfarla","followers_url":"https://api.github.com/users/joostfarla/followers","following_url":"https://api.github.com/users/joostfarla/following{/other_user}","gists_url":"https://api.github.com/users/joostfarla/gists{/gist_id}","starred_url":"https://api.github.com/users/joostfarla/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joostfarla/subscriptions","organizations_url":"https://api.github.com/users/joostfarla/orgs","repos_url":"https://api.github.com/users/joostfarla/repos","events_url":"https://api.github.com/users/joostfarla/events{/privacy}","received_events_url":"https://api.github.com/users/joostfarla/received_events","type":"User","site_admin":false},"created_at":"2015-09-29T06:46:15Z","updated_at":"2015-09-29T06:46:15Z","body":"@ac360 You're right, we have to get the minimum set of features released asap! Today is a busy day for me for work, but I'll see where I can help the rest of the week! Is it an idea to split the changes in several small issues so that we know who's working on what and where help is needed?\r\n\r\nAbout the `postinstall` stuff, I agree these things don't have high priority. The only thing for now is trying to achieve agreement on how we can customize the postinstall proces and extend it with new tasks in the future. In a way we do not have to change the configuring and CLI syntax in a backwards-incompatible manner down the road.\r\n\r\n> How about this for the initial postinstall tasks:\r\n> * Copies npm_module/awsm/ to the aws_modules folder\r\n> * Adds module's CloudFormation template into resources-cf.json\r\n\r\nWhat I'm mainly wondering: are these 2 separate commands or is this one generic command which reads configuration from the awsm.json file? We could provide a set of settings in awsm.json to configure the `postinstall` requirements for that package and extend it in the future with settings for things like interactive installing.\r\n"}}