Package manager should allow dependencies to be placed on other plugins

[park9140]

Currently, packages that are pluggable (such as autocomplete-plus, and AtomLinter) are dependent on their own implementations of plugin style functionality. In order to better support packages like this I think that we should be able to support packages having dependencies.

What I would like to see is capabilities added for the following.

• Subscribe to package manager to get instance of package when it is loaded
• When loaded a subscribed package should expose instance of package created so sub modules can execute against loaded package, for instance if the workspace was a separate module we would get the workspace by subscribing to the workspace load rather than it being available globally on the atom object.
• Ability to subscribe to loaded packages by metadata filter, something like what atom linter does to find linters that have been loaded, but subscribed like we subscribe to all current and future editors.
• A simple interface for verifying version (via semver) of the subscribed package(s) are of the correct version, and when not alerting the user that the modules need updating.

This would give us the ability to dynamically, and bi-directionally link modules to each other.

[izuzak]

Thanks for the suggestion! 🙇 I think there's a related discussion going on in atom/apm#120, so wanted to just link to that here.

[lijunle]

@izuzak Is there any update for this issue? It blocks writing spec for the dependent packages. Because current atom/ci does not have any way to install dependencies, so I need to hack the build-package.sh file to install the dependencies.

[izuzak]

@lijunle No updates as far as I know of. I think atom/apm#120 (comment) explains the current status and the team's thoughts about this.

Sorry if this is causing problems for you and I do understand how useful this ability would be. Once the initiatives the team is focused on currently are shipped, we'll decide what to focus on next (based on everyone's feedback and goals, as we have been doing so far).

[ikatanic]

Are there any updates on this?

[batjko]

@ikatanic These guys are usually quite good with their issue updating. If there are updates on an issue, they will update the relevant issue. If you know what I mean.

[capaj]

have you guys noticed this npm package: https://github.com/travs/atom-package-dependencies ?

[balupton]

For what it's worth, in DocPad land, we use npm's peerDependencies for this, with additional checks around them to ensure compatibility after installation, and on the roadmap for us to also ensure compatibility before installation (by sending what deps are currently installed to our server along with the requested plugin name, then we can return the version of the plugin that is compatible with those deps)

[lijunle]

The behavior of peerDependencies will be changed in NPM@3. They will not be installed automatically any more. I don't think it meets the requirement here.

[balupton]

That's correct, hence why we already add the extra checks, and will be adding such installation magic to our own system, which we plan to abstract out into an independent system, if useful to others.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!