I call them abstract for lack of a better word. Referenced by name? It's not about providing versions of code that does or doesn't pass tests. It's about where

I call them abstract for lack of a better word. Referenced by name? It's not about providing versions of code that does or doesn't pass tests. It's about where that code is fetched from. If you reference the dependency by name then you can easily switch it out for something that looks like the code the author originally developed against, but actually has some changes (patches, bugfix, whatever). Where to retrieve packages from is both a build and a deployment instruction. After all you need to fetch the built packages from soemwhere yes? In general "reference by name and version/abstract" allows you to easily swap in a built package for a source package as well. Otherwise you'd be stuck with whatever formats the author published because the dependencies would be pointing to a specific url (likely outside your control). The very fact you can build a binary package and host it yourself works because of what I call abstract dependencies (for lack of a better name). If they wern't abstract then you'd have to fork the dependent package in order to point it at your built package/repository instead.