Is putting all project dependencies inside project's repository good practice?

Question

I have a project that uses couple (for now ~6) dependencies (other libraries). Most of them are on MIT/simplyfied BSD licences so it should not be a problem to just copy them to my repo.

Would it be good practice to put all those libraries to my repo and push them (and when new versions will come, update them too)? Or my project repo should only contain project files (code, assets etc.)?

Pros:

• building is so much simplier as I have all that I need always close
• added libraries means that I tested my project using those versions, as others (older/newer) might create some problems

Cons:

• bloat in project repo

• have to update dependencies by hand

• if I would like to paste also built versions, I would have to paste a lot of

• files and it would take a lot of space, so probably stick to source only?

• some libraries might have not so nice license and using them directly (other than requiring user to obtain valid library by himself) and placing them in my repo might make some troubles

• having more projects to keep up dependencies would mean that I have to update them for all projects at the same time (e.g. if I make some other projects depending on current project (it's library) then they all will have same dependnecies)

Prowl

Are you currently using anything to manage your dependencies? Using Git to store all your libraries sounds like taking a step backwards from tools like Maven and Gradle. – Maritzamariupol

It's C++, I dont have many options to go. Currently my dependencies are outside of repository and localy i have them installed in git-ignored folder. As for users - i give them info what version they have to obtain and it's up to them to download, compile (if they didn't download binaries) and link them. It's not very nice solution, but is "lets leave it for users to download them all if they want to even build my project" better way? Some repos don't have dependencies outside, some have (like libPNG have zlib in it). I was trying to figure out what is better version for open-source projects. – Prowl

What I have done in some projects: I included the dependencies into SVN/Git as externals/submodules, referring to fixed version numbers. That way I could decide when to update them without having to copy everything manually. Additionally, I set up a cmake build that compiles all the dependencies as well as the main project. That worked quite well so far. (If you want I can elaborate a bit and post an answer, but currently I think this is more of a comment.) – Radke

@anderas: i'd love to hear more about that solution, also try to explain more about this git submodules as i'm average at best in CMake :) But i'd love to hear more from guys who contribute to other libraries and projects (or work in companies) - how do they manage dependencies in their repos - is it included in repo, or some other external script that downloads and builds them etc.? I just don't want to leave all that hard work (for newbies) to build many libs and link them - it might be easy for experienced user, but... – Prowl

Answer 1

Short answer: It depends.

Long answer:

Before you question whether it's appropriate or not to include the code in your repository, you should ask whether it's appropriate to tightly control the dependencies or be more relaxed.

The answer to that depends on how you distribute your project, what your customers/users want, whether you need to make any source code changes to the dependencies, and any other project requirements.

For example, suppose you are selling a hardware device and your code is the device's firmware. In this case, you'll probably want to tightly control the dependencies (require very specific versions). This gives you complete control over the whole system, which simplifies system testing and can be important if your device is subject to certain safety, security, or reliability requirements (e.g., it's a medical device or a probe sent to Pluto). In general, if you distribute your product in the form of a binary or filesystem image, you'll probably want to use fixed dependencies.

If you want users to be able to dynamically link against whatever versions of the dependencies come with their systems (which is valuable for many reasons, including security updates), then you'll probably want to relax the requirements. Make it clear which versions are supported, limit yourself to the documented APIs available in those versions, use a tool to enforce the requirements (error out if a dependency is too old), and test your code against as many versions of the dependencies as possible.

Once you know how tightly you want to control your dependencies, you can then choose the mechanism used to manage them. You could use a tool like Apache Ivy to automatically fetch dependencies, GNU Autoconf to enforce specific versions, or you can pull the code into your Git repository and build it yourself. The specific choice isn't that important; use whatever satisfies your requirements and is easiest for you and your users.

Dropping

Answer 2

If they have a license, I will just follow the licence as explained in this:

https://medium.com/@Vertexwahn/is-putting-all-project-dependencies-inside-projects-repository-good-practice-2b275f4fc3ce

but if they dont have a license, i think the best way is to create a static fork and only update it with changes from original author as you need, and just provide a link to that fork because:

https://docs.github.com/articles/licensing-a-repository#:~:text=However%2C%20without%20a%20license%2C%20the,include%20an%20open%20source%20license.

"However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license."

Immoderate