I currently like the approach of descriptive dependencies at a mix.exs file or maintain a mix.lock. In the end of day I think this is the best practice to run your project anywhere in a more descriptive way.
But I can also see the need for people that want to test or debug something or another inside a project by not necessary having to install the deps inside the mix.exs. I find useful to have a way to install globally libs but I believe it can brings problems with dependency versions more frequently. On Wed, Jul 13, 2016 at 8:23 AM, derek <[email protected]> wrote: > On Sat, Jul 9, 2016 at 11:29 AM, Ben Wilson <[email protected]> > wrote: > > Global package installation is also a constant source of problems when > they > > conflict. That isn't to say that there aren't scenarios where it's handy. > > However great care needs to be taken when it comes to make code globally > > available as we don't want to end up in dependency hell. > > > > It's also worth pointing out that as a compiled language Elixir is > simply a > > different beast than Python. To my knowledge it is not possible to > > consolidate protocols outside of a mix project, and without such > > consolidation there is literally no point in benchmarking anything. If > you > > have a mix project to consolidate protocols, then you may as well just > add > > your benchmarking library as a dev dependency. > > In the company I'm working for there are still lots of components in > pure Erlang, and those Erlang packages are installed globally under > /usr/lib/erlang/lib/... by a Linux package manager like yum; Managing > packages dependencies is not a big deal here I would say, even without > yum; With switching to Elixir doesn't mean we have to rewrite all > components in Elixir, a consensus here is only when rewriting is > proven to have superior benefits; so here why not give user freedom to > manage global packages? not restricting user have to make a fake > project to evaluate something; here benchee is used as a global > package and doesn't belong to any particular project, don't even want > to add into mix.exs > > The current requirement of mix to install a package within a project > is just odd to people with different language background > > This is the proposal: > > $ mix install benchee --save # install the package to > current project, `--save` option is optinal, inspired from `npm > install`, which does add the new dependency to its package.json; for > mix this can be added into mix.exs > $ mix install benchee --user # install into a hidden > directory under user's home, this works for a user with ERL_LIBS > properly set; this is pip's behavior > $ sudo mix install benchee --global # install globally to where > Elixir or Erlang's system libs (that is /usr/lib/erlang/lib to Erlang > usually) > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-talk/CAJctwx42m%2B%2BmzJVV1F0c1ok7WVaO9iGs5PKVT9uxH%2BYqqKCvgQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Pedro Henrique de Souza Medeiros ---------------------------------- Cel: +55 (61) 9197-0993 Email: [email protected] Beautiful is better than ugly, Explicit is better than implicit, Simple is better than complex, Complex is better than complicated. The Zen of Python, by Tim Peters -- You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAJbPmJM8FuCB1P6bYe5%3DwR2jMQt-Eho51TVhY1zJXxS2-GH9ZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
