4 ms·
Adding a second source of truth sounds like a bad idea to me. Now you have to update it in lockstep? No thanks.
by scott_karana 9y ago
Adding a second source of truth sounds like a bad idea to me. Now you have to update it in lockstep? No thanks.
- icebraining 9y agoYou could make the build tool generate this standard file.
- scott_karana 9y agoIt's still a many to many problem in both cases. Option 1: Adding feature to npm/composer/gem/pip ad infinitum Option 2: add per-language parser support to the alerting tool instead. Option 2 doesn't necessitate a new (information-duplicating, still potentially error prone) standard, and can likely leverage available, tested libraries ;-)
- matt_kantor 9y agoOn the other hand, option #1 requires neither effort nor consent from GitHub to onboard new languages/dependency managers.
- adekok 9y agoA few things things: * any non Javascript / ruby / go languages don't have standard packages, package names, etc. * any non Javascript / ruby / go languages may be using one of many build systems. It's just too hard to troll through random build systems to see what dependencies are used * therefore, a simple text file is what will work, and is what will be trivial for everyone to use * if you find it too hard to update one line in a text file when you add (for example) a new dependency on libldap... you shouldn't be programming
- _Codemonkeyism 9y ago" any non Javascript / ruby / go" Would have thought Maven popularized standard package names and build dependency (POM) files.