I work on a Symfony 2 codebase.

We use a number of third-party packages (most are in the Symfony Standard Edition).

We use composer for dependencies.

We current have all of our third-party code committed in our repository (after changing .gitignore files) to ensure stability.

According to Proper Programming Practices™, we are not supposed to have any third-party packages in our repo. We are supposed to pull them down and include them at build time.

How are we to do proper QA and debugging when at any given time our dependencies could push an update that breaks functionality?

  • 1
    "According to Proper Programming Practices™" According to whom?
    – Brandon
    Jun 7, 2014 at 19:37

1 Answer 1


I don't know who told you to pull them at build time, but that person is, perhaps, not in your industry. Pulling at build time means every build is susceptible to upstream changes breaking things in your code. That's BAD.

You need to be keeping a close eye on those upstream repos and pull them frequently when they change (you don't want to get too far behind), but grabbing latest every build? No thank you.

I would recommend doing exactly what you are doing, with the addition that it needs to be someone's job to watch the packages you use and pull changes in as soon as feasible.

  • Pulling fresh copies from the chain is common in automated build systems. The problem is not the pulling at build time, but not properly versioning upstream components of the build. If main package version 1.01 requires library 3.14 then pull from the 3.14 set and not a generic "library whatever, it has the same name" set =) Jun 8, 2014 at 1:34
  • @PatrickHughes - but there are some serious downsides here, even if you manage to pull from the proper upstream tag - what if the upstream repo moves that tag? Accidents happen! What if you don't have a lot of bandwidth? You've just increased your build time for no benefit. What if your net connection goes? You can't build? That's a silly reason to not be able to build. Better to copy these things into your own repo, build from there so you know nothing will change due to someone else's mistakes. If you're anything like me, you'll make plenty of your own. Jun 8, 2014 at 1:41
  • The base point of something in the repo breaking your local build is backwards, the only thing that matters is that your local build doesn't break anything in the repo. The repo is what everyone gets, what releases are built from, and what your check-ins are tested against. If something is broken it's far better to catch it locally before you update the repo with changes that magically "well it worked on the programmer's machine" but break everyone else that tries to use it. Jun 8, 2014 at 6:40
  • @PatrickHughes - I think we're talking about different things. The OP seemed to be discussing the idea of pulling from third-party repos as part of the build, not the OP's main repo. I'm against completely outside forces breaking your build, not your co-workers. Jun 8, 2014 at 16:32
  • We agree, I see your perspective in that light now! Yes, we're approaching his unquoted source of "proper programming practices" error from different sides =) OP, please cite where you picked up this proper practice from, no one does it that way because of everything Michael says here. I know that in my past practice, pulling an external update was a major effort and we locked down everyone's submissions while while merging and regression testing before opening the floodgates again. This was done very infrequently. Internally held versions were pulled on every automated build. Jun 8, 2014 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.