There were some cases where we wanted to reuse those names, or the deprecation warnings were for certain options, but with hindsight, I think something like that could have been a good idea: it could have been an optional module (Decompat?) to avoid cluttering up that namespace.
We aren’t going to change it now, but it is good to keep it in mind for the next major transition.
O.K., I expected something like this.
Maybe into the same direction as @simonbyrne’s idea about an optional module.
Would it be possible to build a package (Decompat or Deprecations.jl) that provides these warnings? I am not a developer and have no idea of how to do that or how long it would take. Could anybody make an educated guess about it?
All the code exists in the git history. Thus if you really think your idea is a good idea you will learn how to make it available as a package. This is open source everyone can do whatever they like. This is also a very friendly forum to get help from people.
Instead of waiting that someone else will implement something you need, you can learn to do it yourself.
My guess is that is not that big project. Although I am not an expert.
Most deprecations from 0.7 are here:
My problem is that my current position does not allow me to do this development during working hours. As I have only very basic knowledge about programming (mainly from self-teaching), I assume that I will need about 10 times as much time as an experienced developer would need. I would be willing to invest a week of leisure time, because that is about as much as I can take away from my family (I have a baby that is currently going through one of those complicated phases, so I need to help my wife).
Accordingly, the question is, whether someone like me can do it within 10-15 hours work.
Considering the amount of time I would need to spend to actually learn what to do and where to get the code from and what to put into the package (not including testing it), and taking into account the time I could spare for it, I assume that an experienced developer might be able to get things finished within possibly 2 hours.
I still think that a package like this would be helpful to new users. The current situation (at least in my eyes) is like this:
linspace or else.All the discussions about deprecations that slow down code show that there is definitively a need for better communication of the deprecations (that’s why I suggested a synopsis). There are also other discussions where the need for better documentation for non-developers was mentioned. Julia has matured to version 1, so one can expect the user-base to shift a little bit towards inexperienced users. Currently, julia still demands a lot of enthusiasm from new users. If it stays like this the user-base will stay very small and all the really impressive work of the developers and this community was for a dead horse.
As @simonbyrne stated above it is now to late to get the deprecation warnings back into julia 1 core. I hope they keep them in the next major transition or supply better information.
The question remains: Can we remedy the current situation easily with either a package or a good documentation (if it is already out there, could somebody please post the link)?
Thank you. Would it work to load this as a macro/module/package at startup of julia v1.0?
I’m sorry if I misunderstand your whole point, but why add the deprecations from 0.7 to 1.0 when that’s precisely supposed to be the difference between the two? Everywhere I look in docs and release notes it’s been said that one should use 0.7 when porting old code instead of 1.0. Sure, that doesn’t cover the use case of someone learning Julia and using an outdated tutorial, but keeping deprecations of older versions surely can’t be the solution to people not informing themselves, right? Personally, I’d much rather deal with people asking about why the code from their tutorial doesn’t work than having people complain about having depwarns from x versions ago…
OT: This seems to be getting mightily off topic from the original topic - it seems this thread is now about why depwarns are not in 1.0 whereas the original post was more about how the transition itself was annoying for someone because they didn’t read the release notes before upgrading… Just my two cents though.
My appologies: I mean to have the informative error messages like @ric.cioffi suggested.
You are probably right. Can somebody (possibly @simonbyrne) split this discussion into a new topic?
In my opinion, the single most disappointing thing about the release of Julia 1.0 has been that it came out just a few hours after Julia 0.7 (and the lack of communication about this), with the result that everyone skipped it, completely defeating the purpose of that release as a bridge between 0.x and 1.0.
At the beginning of August most of my packages were almost 1.0-ready (I only had issues with very late breaking changes like iterator protocol), but I was in vacation and didn’t expect to see Julia 1.0 released so soon, thus none of my package worked for the first week on Julia 1.0.
Hm. Those messages are the deprecation warnings though, just displayed as an error instead of a warning. That’s what the --depwarn=error julia argument does. If you’re proposing to have the depwarns in 1.0, there’s no reason to actually have 0.7 in the first place. Furthermore, the depwarn is just supposed to be an informative message about a future removal of functionality. Code from 0.6.x still works fine on 0.7, it just also displays that message. The functionality used previously doesn’t exist anymore on 1.0, and the depwarn gives the information what to replace it with on 0.7.
If there was some time between 0.7 and 1.0 or some note appeared when starting 1.0 for the first time (“This is a new major version - if you’re upgrading older code or want to change habits, use 0.7 with deprecation warnings.”), I think all of that annoyance with “Why does my code not work” would have been avoided and as far as I know/read on discourse here, the plan is to do just that. It seems that people don’t really want to read release notes if they can avoid it and just want to use the latest version - in which case they hopefully are aware that a major version jump is going to be breaking and are not surprised that it actually is.
While you are correct about this, in retrospect I think it is recognized that the purpose of 0.7 was not communicated widely enough. This was fixed ex post:
and I think it is reasonable to expect this will be done differently next time.
Maybe it’s possible to link that post (maybe even the release notes) or add a short text like it to a first REPL startup of 1.0.2 or add a small disclaimer in a future major version?
I don’t agree. Version 0.7 displays the warning in combination with an automated “translation” into the new function (that’s at least what happens for linspace: The deprecation warning is displayed, but at the same time a range command is run with the same start and stop values and a default number of 50 steps). What I want to suggest is to have the warnings/error messages in version 1.0 without the automated solution.
Currently, version 1 only throws the error “command not found”. When I ran into this issue, I was trying to recapitulate some examples I had found, which I tried to adapt to my purposes. When I got the error my first guess was that I had a typo (I tend to type uppercase characters at the beginning of a command). Then I checked the syntax, which was fine as well. It took me some time to figure out that those examples were from an older version of julia and some commands had been deprecated. As I had already seen the PSA mentioned above, I got the idea to install julia 0.7 and test the linspace command. There I got the answer and was able to solve the problem pretty quickly. However, this needed some research, that might repell other potentially new users.
I now know, that I need julia 0.7 alongside 1.0, even though I have no previous codebase that needs upgrading or workflows that need to be adopted. This is unfortunately not mentioned in the PSA.
If julia 1 had thrown the error message “command not found” together with the information about the deprecation of linspace and the hint to use range, the whole issue would have been solved much faster and more easily.
It seems clear to me from reading this and many other threads that there is a subset of potential Julia 1.0+ users who fairly reasonably would like to explore using the language, but haven’t been around for much of the preamble and are understandably a bit perplexed when they encounter some of the (however transient) rough edges. And it seems (or I’d guess) that a fair number of these people are also looking to use Julia, at least initially, much more using the REPL than by creating modules, packages or even .jl files.
Accordingly I think a practical and easy change would be to make it so that the startup banner in the REPL by default included some pointers to key documentation explaining what 1.0 means w.r.t. 0.7 and previous versions etc, then that might go a long way to those users figuring at least part of the story out for themselves.
So that it isn’t a nuisance for users who are already informed of the issues here, there could be some magic REPL command that would turn off this feature.
Also, I’m not sure if it’s feasible but if there was some heuristic way to (again probably only when the REPL is being used) to detect some of the most common things that trigger these annoyances and help point to appropriate documentation then that could go a bit further.
If people think this might be useful I wouldn’t mind taking a stab at a PR. Pretty sure I could do the banner part; the heuristic would surely require some assistance from those much more familiar than me.
Just to save some hypothetical person time and energy, we’re not going to put old deprecations back in the language. If you want to help, then please update examples wherever you find them.
No, I don’t think that’s what’s happening. I can’t check right now, but as I understand it, on 0.7 the old function is run and additionally that deprecation warning is displayed with the (also available on 0.7) new version as a proposed alternative. That’s what a deprecation warning is, a notice about a future unavailability of some thing, with that thing still being accessible for the moment. On 1.0 that old function simply doesn’t exist anymore, which is why you get the method error in the first place. There’s no way to mark a function as deprecated that doesn’t exist anymore and it frankly doesn’t make sense when that function has a deprecation warning in a previous version and the removal has been properly documented (such as in the release notes of both the version introducing the deprecation as well as the version actually removing the function).
As for the rest of your post: The linked post definitely applies to you too, as it also mentions “just changing habits”. There’s nothing wrong with exclusively using 0.7 for the moment, until you’ve adapted your habits. However, if you want to develop stuff after updating your code and habits, switching to 1.0 is the reasonable choice, to prevent using older syntax by accident.