Dependency hell when upgrading to new Elixir versions (i.e 0.13)

250 views
Skip to first unread message

Steve Pallen

unread,
Apr 5, 2014, 11:32:42 AM4/5/14
to elixir-l...@googlegroups.com
Almost every time I try to upgrade to a new release, I got through dependency hell. I use a number of deps like ExActor, AmRita, Reagent, which themselves have dependencies like elixir-datastructures. Most of these packages are not forwards compatible due to their mix files and how quick features are deprecated and removed in pre 1.0 Elixir. So, I'm stuck with forking, updating, and maintaining these dependencies myself. 

Are others having this issue? Am I doing something wrong?

I'm building a telephony system with Elixir which we will be selling in a couple months. I'm ready for a smoother transition between version upgrades. 

How can I help? Here are a couple ideas / suggestions:
  • Can we keep a mapping of package support to Elixir versions. ie 0.12.4 (ExActor, AmRita, etc), 0.13.0 (none)
  • Should we write a tool to do the same?
  • Can package developer use a more forward compatible Elixir dependency?
I look forward to any input that makes my life easier or how I can contribute to help others with the same issues.

Steve

José Valim

unread,
Apr 5, 2014, 11:54:38 AM4/5/14
to elixir-l...@googlegroups.com
Are others having this issue? Am I doing something wrong?

I am definitely having this issue too.

The main issue right now is that people need to be pessimistic in their Elixir dependency because Elixir can break APIs in new releases. I had considered following some kind of SemVer before 1.0, basically to not insert breaking changes on v0.12.Z, v0.13.Z and so on, but then I realized that almost every new release would be a v0.Y one, which results on the same problem.

There are a couple things coming though that will help alleviate this:

1. In v0.13, we are just printing a warning for incompatible Elixir versions. This means you can at least *run* your code during migration and figure out for yourself if your code works;

2. Eric is working on a package manager (called hex) which should make updates easier;
 
Also v0.13 is completely backwards compatible with v0.12.5 so at least for this update you can just send a pull request that adds "~> 0.12 or = 0.13.0" to existing projects.

I'm building a telephony system with Elixir which we will be selling in a couple months. I'm ready for a smoother transition between version upgrades. 

Nice! :D
  • Can we keep a mapping of package support to Elixir versions. ie 0.12.4 (ExActor, AmRita, etc), 0.13.0 (none)
hex should help here.
  • Can package developer use a more forward compatible Elixir dependency?

Unfortunately I don't think so. Which I understand is a major part of the problem. We do emit deprecation warnings and keep the CHANGELOG updated but it still means frequent efforts for upgrading software. And we will be relying on those more now since we gearing towards 1.0.

Saša Jurić

unread,
Apr 5, 2014, 12:45:08 PM4/5/14
to elixir-l...@googlegroups.com
Hi Steve,

I'm sorry you have problems with ExActor. To be honest, I didn't yet invest any time trying it out on new Elixir, since 0.13.0 is not yet released. I realise it's a bit selfish / lazy on my part, but due to time limitation I didn't want to do some work on an unstable version, only to have to redo it again if something changes.

That being said, as soon as 0.13.0 is released, ExActor is the first library I'll migrate. Of course, if you happen to have done something already in that compartment, pull request is welcome, but otherwise, I plan to do it fairly quickly.

I also used to keep release tags that correspond to Elixir versions. I removed those fairly recently, but the migrated version will definitely be bumped, with both tags kept, so you should be able to get one or the other.

If you feel something else is needed, let me know.

Steve Pallen

unread,
Apr 5, 2014, 1:39:08 PM4/5/14
to elixir-l...@googlegroups.com, jose....@plataformatec.com.br
I think i'm still missing something here. The fact the packages won't compile because they have specified their dependencies to a specific version of either Elixir or another packet is what I'm struggling with. I've never come across this with ruby for example. However, I've never studied how it does dependency management either. However, I could not imagine the nightmare if all the gems developed for 1.9.2 could not be installed for 1.9.3  or even 2.0. Will hex solve this? Is this not just a matter of package designers using "> 0.12" for their dependencies. Or, perhaps the ability to only warn of these during mix dependency changes (or is that already a feature?).

I woud much rather have my app compile and find any potential incompatibilities in my test suite, then be forced to fork the package, change the dependencies and test in speculation of a potential future incompatibility. 

Thanks

Steve Pallen

unread,
Apr 5, 2014, 1:54:56 PM4/5/14
to elixir-l...@googlegroups.com
Thanks Saša,

I think I jumped the gun trying to get my app running on 0.13.0 since its not released yet as you indicated. However, not all contributors in the community are responsive as you and José :)

BTW, I really like ExActor. I used once a couple months ago, and just used it again yesterday. I have a number of gen_servers that I'm considering converting to ExActor. You sound like you have long term plans for its support. If so, I may use it more extensively.

Regards,
Steve

José Valim

unread,
Apr 5, 2014, 3:37:28 PM4/5/14
to elixir-l...@googlegroups.com
> I think i'm still missing something here. The fact the packages won't compile because they
> have specified their dependencies to a specific version of either Elixir or another packet
> is what I'm struggling with.

This happens because Mix introduced an elixir requirement configuration that forces a
particular Elixir version. It is useful, in those times of change, because you know exactly
which version it was designed to run against.

The downside is exactly what you are experiencing. That's why v0.13 is going to help because
we are not going to stop you from working, we will simply emit a warning.

It is a lesson that we learned the hard way but we are improving. :)

Since you mentioned gems, the solution would be the equivalent to printing a warning when
the gem is loaded saying that the author did not specified your current Ruby version as
supported.

> Or, perhaps the ability to only warn of these during mix dependency changes (or
> is that already a feature?).

Yes, this is exactly the feature I am talking about that will be in v0.13.



José Valim
Skype: jv.ptec
Founder and Lead Developer


Reply all
Reply to author
Forward
0 new messages