Is This Redundant? about package-deps

[steelbrain]

@joefitzgerald These two packages have different purposes, they share one purpose however, to install dependencies. This package accepts an array, which makes sense because we don't want to enforce versions of packages. That package accepts an object with version that do nothing at the moment (but maybe some time in the future?). This package's install method accepts a package name and does nothing if they are installed already, according to README of that package, it forces a re-install (which is not what we all want).
If you depend on multiple packages, this package provides a nicer progress bar and a notification if you're depending on one, but there's no concept of such a thing in that package. This package provides a promise-based API that resolves when all of the dependencies have been installed. but in that package, You have no idea if they have been installed or if one of the installation has failed.

Also, the purpose of that package is to install the dependencies, and then require them. It might be useful for packages that extend the tree-view and similar ones, but it fails to be the best one to use when depending your package on linter.

They have quite a lot of differences, and because that package is only a single file, I said why not write our own and maintain it ourselves?

[joefitzgerald]

So you're looking for package sets then: atom/apm#385. I'm not convinced this is sufficiently different from anything else, or that you're adding novel features. Might it be more useful to contribute to something that exists already?

You certainly don't need to take my advice though, this is just a suggestion.

[steelbrain]

@joefitzgerald I think so. There's no documentation for package sets so I can't exactly tell but if package-sets mean that you install linter-* and linter gets installed automatically then Yes. I would love to discontinue my package when package-sets arrive.

I do have Contribute to Atom Core on my Todo list but I am a bit busy these days so won't have enough time to examine a codebase I am not familiar with.

[steelbrain]

Closing but can keep discussing.

[Arcanemagus]

From my understanding of the two sets of code they do essentially the same thing. atom-package-dependencies does not force re-installation, unlike what it's documentation claims.

The primary differences that I can see between the two packages is that atom-package-dependencies calls apm ls -b and parses the results to see what packages are currently installed, while this one queries the atom API to check that. The error checking in this package is slightly more robust as it checks for the ✓ mark, while the other just checks that there was any output at all.

I'm sure there are things that I'm missing, but that's what I saw while quickly looking over the code.

[thedaniel]

@steelbrain The docs for package-sets really don't exist because it's work that is still ongoing. Joe and some other folks were interested in it so we hashed out the details in a chat over the course of a week or two. The PR Joe linked above is worth reading in case the concepts suggested there meet your needs - since it's something that we're already interested in having in core, it might be worth taking a look before you charge fully into your own package set implementation that might get superseded by core in short order. There might be some info that didn't make it from chat into that PR but @joefitzgerald can def clarify anything over there if you have questions.

[steelbrain]

@thedaniel As soon as that PR lands, I am happy to discontinue this. It's just that we get tons and tons of people who have installed linter-* and doesn't have linter, this package is a super simple one, nothing complex. We decided on our google hangout that we're gonna build this package until that feature arrives in the Core.