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)

Answer 1

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."

Answer 2

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.