
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><blockquote type="cite"><div>The strongest reason I can see to build an Erlang centric PM is to support Erlang's existing deployment behaviors i.e. releases.<br></div>

</blockquote><div> </div>

<div>An Erlang centric PM should not do anything regarding releases. <br></div>

<div> </div>

<div>The PM should focus on development and not for deployment. Releases should be used to build target systems and deployed as such, maybe the libs that are used to build the release/target system were fetched with the PM at some point but the PM needs no knowledge of releases.<br></div>

<div> </div>

<div>As for npm, gems, bundler, maven I know little about any of them. Except that one is worth millions of dollars or something... And relies on CouchDB and has hilarious outcomes when someone breaks semver rules. Anyway... I don't think there is anything people are proposing we take directly from those, instead to learn from prior art -- I'd suggest more opam/cabal/cpan than those as useful prior art though.<br></div>

<div> </div>

<div>Cargo, http://crates.io, is an example of the condensed knowledge taken from those projects into a new package manager. <br></div>

<div> </div>

<div>But I do like Maven's(and thus Leiningens) dependency handling, highest spot on the dep tree wins. And we are using that for rebar3.<br></div>

<div> </div>

<div>Tristan<br></div>

</body>

</html>