4 ms·

"10. Dependencies need a home too" I agree with this statement, but that home is definitely not with your code. There are tools better suited for that. For ins

by Xixi 15y ago

"10. Dependencies need a home too" I agree with this statement, but that home is definitely not with your code. There are tools better suited for that. For instance nexus & maven. Nexus store artifacts (which are really any piece of data: a jar, a tar.gz, a zip file). That's where you put your dependencies. Maven manage a project's build, that's where you tell what are your dependencies. But really, there are many other tools out there to handle that (ant, nant, pypi, etc.).

joeyespo 15y ago
Agreed. It's a problem, but VC just isn't built for dependency management. Since the histories of the dependencies don't get tracked, merging them can be tricky. Especially when dependencies get upgraded separately by multiple people.
moe 15y ago
It's funny to see someone defend Maven in 2011. However, yes, checking in dependencies with your code is the way to go. Deps that can be reliably included with just a meta-descriptor (i.e. Gemfile, pom.xml, etc.) are still exceptionally rare. Thus the natural choice is to put the rest right next to the code that it belongs to. Well, natural choice unless you're stuck in a 90s java mindset...
- CodeMage 15y ago
  What's wrong with Maven? I'm asking this as someone who hasn't used it and who wanted to give it a whirl. Any input would be much appreciated.
  - gchpaco 15y ago
    If you want to do something simple it takes a 60 line pom.xml to express it. If you want to do something a little trickier it takes another 60 lines and three hours minimum of poking around at inadequately written docs. If you want to do something difficult, forget it. Ant, which is a nightmare of usability and continues to make me wake in the middle of the night screaming, is at least as complex to configure, better documented and is not a quarter as constrained as Maven. That said the Maven dependency model isn't too bad; fortunately you don't have to adopt Maven to get it, you can just use Ivy.
- efsavage 15y ago
  You've got that backwards. The "90s java mindset" is the lib dir. The 2011 approach is Maven, as evidenced by the fact that 100% of my clients use it, and practically every major open source project uses it as well. Perfect? No. But standard practice? Yes.
mellery451 15y ago
I agree with you - the "not invented here" libs don't belong in your repo. I'm always amazed when I walk up to a "mature" base of code and find third party and open source dependencies festering all over the repository. This drives me crazy. There is just NO reason this stuff needs to be in source control. It's pure laziness that drives developers to just punt and check whatever version they happened to be using during dev. This makes final packaging as well as future upgrading a nightmare (particularly if other projects have glommed-on to the same dependency in the meantime). The lowest-budget solution is simply to store the third party and open source projects in a reliable network file share (NFS, samba, etc). Then you can either sync locally or just build/link directly against the mounted file share. It's also important to keep each project in a directory structure that includes the version number in the path (e.g. /nih_libs/boost/1.44.1/...) so that you can easily drop in a new version and start using as needed on a project by project basis. I'm always amazed how many places neglect this step and then have nothing but pain when they want to upgrade to a new version of a lib.
- curious_man 15y ago
  I still don't understand why dependencies don't belong to the repo. My naive reasoning: I just have to clone the repo and bam, I already have all the dependecies needed to build the artifact. When I need to upgrade to a new version of a library, I only have to commit a new version and delete the old one (possibly integrating the new library in a separate branch if the process is not trivial). Can you elaborate a bit more on this?
  - undees 15y ago
    If you use something like Git submodules, Mercurial subrepos, or Subversion externals, you can get the best of both worlds. Your repo contains just your code, but a fresh clone will set up dependencies automatically. I've also seen really simple projects get by with just an "install_deps" task in the Makefile, which you run first thing on a new clone. ("The simplicity of Maven meets the dependency management of Make," the wags will say.)
    - 15y ago
ylem 15y ago
This is a legitimate question--but what if you need to support different versions of open source packages and you need to be sure that they will exist years later. This is something that I'm facing now in that I may be using numpy 1.2.x, but suppose someone else is using numpy 1.3.x and we all need to play well together in a distributed environment--the context needs to be stable. If I don't put this in source control, then where's a good place to stash it so that I can reconstruct the various contexts when I have to migrate to a different server?

by Xixi 15y ago

joeyespo 15y ago

Agreed. It's a problem, but VC just isn't built for dependency management. Since the histories of the dependencies don't get tracked, merging them can be tricky. Especially when dependencies get upgraded separately by multiple people.

moe 15y ago

It's funny to see someone defend Maven in 2011. However, yes, checking in dependencies with your code is the way to go. Deps that can be reliably included with just a meta-descriptor (i.e. Gemfile, pom.xml, etc.) are still exceptionally rare. Thus the natural choice is to put the rest right next to the code that it belongs to. Well, natural choice unless you're stuck in a 90s java mindset...

CodeMage 15y ago
What's wrong with Maven? I'm asking this as someone who hasn't used it and who wanted to give it a whirl. Any input would be much appreciated.
- gchpaco 15y ago
  If you want to do something simple it takes a 60 line pom.xml to express it. If you want to do something a little trickier it takes another 60 lines and three hours minimum of poking around at inadequately written docs. If you want to do something difficult, forget it. Ant, which is a nightmare of usability and continues to make me wake in the middle of the night screaming, is at least as complex to configure, better documented and is not a quarter as constrained as Maven. That said the Maven dependency model isn't too bad; fortunately you don't have to adopt Maven to get it, you can just use Ivy.
efsavage 15y ago
You've got that backwards. The "90s java mindset" is the lib dir. The 2011 approach is Maven, as evidenced by the fact that 100% of my clients use it, and practically every major open source project uses it as well. Perfect? No. But standard practice? Yes.

mellery451 15y ago

I agree with you - the "not invented here" libs don't belong in your repo. I'm always amazed when I walk up to a "mature" base of code and find third party and open source dependencies festering all over the repository. This drives me crazy. There is just NO reason this stuff needs to be in source control. It's pure laziness that drives developers to just punt and check whatever version they happened to be using during dev. This makes final packaging as well as future upgrading a nightmare (particularly if other projects have glommed-on to the same dependency in the meantime). The lowest-budget solution is simply to store the third party and open source projects in a reliable network file share (NFS, samba, etc). Then you can either sync locally or just build/link directly against the mounted file share. It's also important to keep each project in a directory structure that includes the version number in the path (e.g. /nih_libs/boost/1.44.1/...) so that you can easily drop in a new version and start using as needed on a project by project basis. I'm always amazed how many places neglect this step and then have nothing but pain when they want to upgrade to a new version of a lib.

curious_man 15y ago
I still don't understand why dependencies don't belong to the repo. My naive reasoning: I just have to clone the repo and bam, I already have all the dependecies needed to build the artifact. When I need to upgrade to a new version of a library, I only have to commit a new version and delete the old one (possibly integrating the new library in a separate branch if the process is not trivial). Can you elaborate a bit more on this?
- undees 15y ago
  If you use something like Git submodules, Mercurial subrepos, or Subversion externals, you can get the best of both worlds. Your repo contains just your code, but a fresh clone will set up dependencies automatically. I've also seen really simple projects get by with just an "install_deps" task in the Makefile, which you run first thing on a new clone. ("The simplicity of Maven meets the dependency management of Make," the wags will say.)
  - 15y ago

ylem 15y ago

This is a legitimate question--but what if you need to support different versions of open source packages and you need to be sure that they will exist years later. This is something that I'm facing now in that I may be using numpy 1.2.x, but suppose someone else is using numpy 1.3.x and we all need to play well together in a distributed environment--the context needs to be stable. If I don't put this in source control, then where's a good place to stash it so that I can reconstruct the various contexts when I have to migrate to a different server?