See
cap julia version for probably-0.7-incompatible packages by StefanKarpinski · Pull Request #685 · JuliaLang/Pkg.jl · GitHub and the result of this for the registry is at https://github.com/JuliaRegistries/General/pull/16.
Might be nice to test only the ones that have the explicit compatibility.
Right after a new release is absolutely the most frustrating time to try it out, since (as you discovered) the package authors need some time to catch up. Python 3 wasn’t exactly easy to use on day 1 either, so this is just the normal pattern. Give it a couple weeks and try again?
I suffered enough with Python 3, but even R 3.5 had a big gap still now.
Yes. You have to wait for packages, but I don’t think conda use to install incompatible ones! (sometimes it could happened but it is rarely)
Docs says: "Since environments are managed and updated independently from each other, “dependency hell” is significantly alleviated in Pkg. "
But in reality Pkg doesn’t help much here. Does it really check any dependency if it install so many incompatible packages?
In contrary - it seems (show me if I am wrong) to be far behind Conda or similar package managers.
I am not complaining (yes it needs much works and I am not going to pay it). But I think that more realistic view could be helpful.
Go to .julia/registries/General run a git fetch and git checkout kc/the_great_cap. It will apply the actual semver. Problem is a bunch of packages didn’t take the new semver seriously.
Can you open a little bit more? I think here is a great learning opportunity for me. Also a link to the previous discussion is enough.
From the docs. A package specifies the Julia compatibility in the Project.toml/(or REQUIRE for now). However, many packages wanted to just specify 0.7 which actually means [0.7, 1.0) meaning it ends up saying is not compatible with 1.0. There is a PR to General to apply the semver which makes packages that have specify no compatibility with 1.0 with no version suitable to install for Julia 1.0. Many packages ignored it for now since it just works differently for now.
Thanks. I am guilty as well. @ahojukka5 asked what should we put to the REQUIRE and I agreed with the wrong way. To my defence until now it meant no upper bound (because the implicit upper bound was 1.0) and we wanted to keep it this way until we will actually move to toml.
Correct entry to REQUIRE is?
julia 0.7 2.0
I think REQUIRE had a different system in the previous Pkg manager, but I think that it should use the same as the new Pkg manager now so yeah.
@kristoffer.carlsson, @StefanKarpinski, is that correct about the semver for REQUIRE at the moment?
Agreed. However, many people won’t try again. They hear/read somewhere “Julia 1.0 is finally out”, go to the website, see a big “Download 1.0” button, try it out, and are disappointed in so many places (mostly but not exclusively the ecosystem). Maybe, they even make their way to discourse but then read a (probably correct) post like this one by Steven and are even more confused and annoyed.
Just the fact that IJulia doesn’t work on 1.0 on Windows yet, made many of my colleagues almost lough and say statements like (“This is supposed to be a 1.0 release?”). Of course, they don’t consider that most people develop these packages in their free time etcetera, but I guess that’s how the majority of “customers” are. Despite the fact being open-source, Julia competes with solid software like Matlab and Co and users won’t really care about “why” Julia 1.0 isn’t yet what it, for sure, will be.
Even me, an intensive user for about 2 years now, is a bit overwhelmed by Julia 1.0. Frankly, I sometimes feel like “it’s not quite there yet” in the sense of “hopefully they will release a 1.0.1 soon where they smoothen out things” (like the range(start, stop; kwargs...) or even more importantly the global scoping issue). So many changes have been made. Knowing the community for a bit, I believe most of them happend for a good reason , which one can find in a PR somewhere, but the number of changes was so huge that I couldn’t make up my own opinion in those PR’s at the time simply because I couldn’t keep up with the speed. For this reason, there seems to be a wave of (minor) complaints now (this relates to Stefan’s understandable, statement here) which can only be fixed in 1.x.x. In this regard, maybe it would have made sense (wildy speculating) to release the current 1.0 as “0.8” and kind of rename it to 1.0 once packages have been upgraded (0.7 had deprecations and also was only released for about two days). From a marketing perspective, 1.0 is a magical version number.
However, having said all that, I want to make clear that I love the language and the effort of everyone involved in creating it! Instead of just commenting here, I try (with all my energy) to convice my colleagues that Julia is and will be great. I think it’s really important for everyone who loves the language to contribute now (as fast as possible!). In particular the documentation has to be improved in many ways given the number of simple usage questions here. Make it easier for people to use the new package manager. I myself try to answer questions on stackoverflow as quickly as possible such that people get the feeling “ok, Julia has some issues but they helped me right away!”. Now is the time.
(Sorry for the lengthy post and for slightly derailing this thread.)
I’ve seen what you’re talking about first-hand: within days of the release of 1.0, someone in my lab who had never made the switch finally decided to download it and give it a try. As noted in this thread, it was a very frustrating experience. I was able to explain and help manage expectations, but not everyone has a core developer within such easy reach. It might not have been crazy to have parked on 0.7 for a month and then released 1.0, but what’s done is done.
The plus side is that I’ve never seen so much energy and enthusiasm being pored into updating packages. We had literally >100 developers stay for a day after JuliaCon and upgrade packages. New tags are being released so quickly that the folks who are merging to METADATA must be struggling to keep up. We all feel the pressure (sleep? what’s that?). The major upside is that I predict this transition, given its difficulty due to the extent of changes, is being made at a rate that may have no precedent in the history of open-source languages.
Just to adjust expectations: waiting an extra month or six would not have made Julia polished in the sense Matlab/R/Stata/… is. The package ecosystem will probably take years to develop mature libraries. In a lot of ways, 1.0 is the beginning of the journey, not the end; having a stable release should facilitate focusing on packages.
Many are already using Julia productively, and have been doing that for years. There is a price to pay in terms of convenience, but there are also great benefits. Those who expected a plug-in replacement for, say, Matlab, have somewhat unreasonable expectations about open source projects.
If will take time for the whole package ecosystem to evolve but I personally think that key packages like IJulia, IDE (vscode/Juno), etc. need to work soon. Those are the things that first time users will try immediately.
The disconnect in perception is that people want to use Julia the System, but what was released as 1.0 was Julia the language.
I have been encouraging people at my lab (an on forums) to wait for a few months more. But a disclaimer on the homepage would really help. As it is now it shows off the ecosystem and all the things you can supposedly do, when in reality you really kind of can’t. Even saving and recovering data reliably in hdf5 isn’t quite there. This is not a question of maturity but of communication clarity.
I think other open source projects have managed processes like this better (and many have done a lot worse). Rust had a stellar 1.0 release. Stable, excellent documentation, and a clear package system with clearly articulated deficits. Python had a disastrous 2->3 transition that is finally coming to an end over a decade after it started.
Overall Julia has a great community, but right now there is a lot of feedback that is negative just after the developers have finally achieved an excellent 1.0 release. I hope that people manage to take something constructive from these posts. Don’t just say “well it’s open source, what do you expect?” but “I hear you and your experience, let’s see how we can make things better”.
I don’t see why people should be advised not to use Julia now. True, some packages don’t work. But there are many that do. If someone is not well served because some packages do not work, there are usually alternatives.
What is a real problem are the exaggerated expectations that with 1.0 everything is working. That is obviously not true, but in my opinion that is not a reason to advise people not to use Julia.
Julia works right now for some people (me included). It clearly doesn’t work for others. You should be judicious about whom you advise to use it, and whom you advise to wait until the ecosystem, the documentation and the tooling have improved.
Also, again, take that info as input: People have unrealistic expectations. Why? What led them there and how can we correct that? Look at the landing page of Julialang. It’s not unreasonable to come away with inflated expectations about the state of the ecosystem. It would be helpful to newcomers if it said there somewhere:
Julia is a language with which you can do a, b, c and it’s great for developing scientific code. The language is stable now, so now is a perfect time to start exploring and developing. Here are a selected few standout packages that work right now, many more are transitioning to 1.0 as we speak. Here is a list of compatible packages.
Perhaps you meant that some packages don’t work, not “Julia”, which is the language/binaries and is usually pretty stable (for the released version).
I am not sure we should be assuming responsibility for unrealistic expectations of other people. In any case, being grownups, they are free to download Julia, invest a bit of time into learning the language, and then decide for themselves.
If someone expects a polished set of packages that they can just use as a plug-in replacement for their existing workflow in language X, and refuses to put any effort into fixing issues, they may be disappointed with Julia at the moment. But at the same time, it is also unclear what the community would benefit from users like that.
BTW, what @ChrisRackauckas writes at the end of this post (“The Evolution …”) is also very relevant here.
You can approach this in a constructive way or just shrug it off. I’d prefer it people try to be understanding and build a community open to newcommers.
If someone doesn’t have the capacity to implement all the algorithms they need in their daily work, or the time to debug a whole host of installation issues (and we’re not talking obscure stuff here), then Julia does not work for them right now. That’s most people at my lab. Pedantically specifying that “Julia” only refers to the language, and in a specific narrow technical reading it “works” is not helpful here.
I also don’t understand what Rackauckas comment contradicts anything I wrote. If anything it points out the following: Julia is not new, it’s battle tested, it’s mature, and its veteran users project that image and self understanding. And given all that it has just had a rather unprofessional 1.0 role out.
Maybe to reiterate: The point of listening to newcomers experiences is not necessarily that they are right. They usually will not be, but to learn better how to communicate and teach them the Julia way. To learn where their misunderstandings come from. Hopefully then in the future we get a virtuous cycle where people come here less confused, their feedback becomes more constructive, etc. Again, look at the Rust community. They have been advocating a language that is as radically different from C as Julia is from Python (maybe more so), and have managed to continuously grow by paying meticulous attention to these issues. Julia seems to sometime take it’s queue from the worst impulses of academia here: “Well I proved it, you can’t expect me to also explain it”.
I didn’t wanted to comment on this, but can someone (of the there-is-no-problem-with-1.0 group) just open julialang.org, scroll down to packages and click on Ecosystem Pulse https://pkg.julialang.org/pulse and read “Last updated 2018-08-04”.
A constructive discussion would require something concrete to start with, eg “I tried installing Julia and it failed with this error message”, “How can do X in Julia?”, etc. People are asking these kinds of questions here and on different forums, and are usually getting solutions (or at least an open issue, which will hopefully lead to a future solution or a workaround).
Lacking anything concrete, it is very difficult to solve these things “constructively”, and I am curious how you propose we do that.