Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How would you effectively do this in a way that is cross-build-platform friendly? CMAKE? autoconf? submodules?

I don't see that happening.



Text files?

If people get value from it, editing a simple text file once or twice a year wouldn't be difficult.


Adding a second source of truth sounds like a bad idea to me. Now you have to update it in lockstep? No thanks.


You could make the build tool generate this standard file.


It'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 ;-)


On the other hand, option #1 requires neither effort nor consent from GitHub to onboard new languages/dependency managers.


A 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


" any non Javascript / ruby / go"

Would have thought Maven popularized standard package names and build dependency (POM) files.


Even more than that, Maven came up with the groupId concept, which I think is under-utilized by many other package managers... The leftpad fiasco could have been mitigated with it, for example.


How many C / C++ projects use Maven?


I see.

A text file that just declares that "this project uses lib 2.1". It isn't a part of the build system in any way.

That would be awesome.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: