# Handling various types of dependencies

**URL:** <https://discourse.julialang.org/t/handling-various-types-of-dependencies/27850>\
**Category:** General Usage\
**Created:** [August 22, 2019, 2:45pm UTC](https://discourse.julialang.org/t/handling-various-types-of-dependencies/27850 "2019-08-22T14:45:38Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [August 26, 2019, 2:10am UTC](https://discourse.julialang.org/t/handling-various-types-of-dependencies/27850/17 "2019-08-26T02:10:43Z")

</div>

> [@hendri54](#):
>
> why this design decision was made

I think you can find an answer in this comparison of Julia’s Pkg to Go’s packaging system:

> [@Pkg3 vs. Go's vgo](https://discourse.julialang.org/t/pkg3-vs-gos-vgo/10154):
>
> The other day I came across the post [A Proposal for Package Versioning in Go](https://blog.golang.org/versioning-proposal) in Go’s blog, and the following passages in particular (edited for clarity) got me wondering about whether these concerns (and corresponding proposed solutions) apply to Pkg3. They start by describing their current approach: […] we all believed the answer would be to follow the package versioning approach exemplified by Rust’s Cargo, with tagged semantic versions, a manifest, a lock file, and a SAT solver to decide w…

Go is treating packages with different major versions as essentially different packages. So the above scenario would have “worked” in the sense that PkgC would load PkgB 2.0 instead of PkgB 1.9.

---

_[View the full topic](https://discourse.julialang.org/t/handling-various-types-of-dependencies/27850)._