Sorry, I still don’t understand. As I said, earlier versions of JuliaPro are still available, were they updated to remove bundled packages?
Try downloading J-Pro 1.0.x and installing it, then start the package manager and issue an st(atus) command.
As I said I did not want to get detracted on the merits, or otherwise, of J-Pro; although for my talks to the non-Julia community it was a convenient suggestion as to how they could start.
I believe that J-Pro keeps a separate repository, but when adding a package which is not there defers to the main one, but that is heresay on my part. If so it does mean that one is never quite sure where the source is coming from!
Apparently we still don’t understand each other. I am curious what has been “taken away” from the users of 0.6.x when 1.0 was released.
Sorry, but I don’t understand who/what is detracting you. I don’t think I said anything to that effect.
This conversation on J-Pro, which was not part of my original comments as it would detract from the rest of the article.
I have been told in a private communication that v0.6 is dead and should not be used, so downloading older versions of J-Pro (v0.6) seem to have little merit.
I’m just confused on that comment though. JuliaPro v1.0 still comes with the packages pre-installed, and is still pretty much the same list.
Sorry, I don’t understand what your point is.
Of course now that the package ecosystem has more or less caught up, using 1.0.2 (and soon 1.1) is the recommended solution. But at the time of the 1.0 release, while a lot of packages were still in the process of being upgraded, continuing on 0.6.x, with or without JuliaPro, was a perfectly viable solution. Nothing was taken away, and everyone who was more sensitive to the disruption of upgrading could wait it out.
Post 1.0, the release process is now more formalized (see especially the “Risk Tolerance Personas” part).
The one criticism I still find valid is the PkgEval infrastructure is still not up to public API / user consumption. It is used internally, but the official website is still the old one.
My point(s) are the following: new users to Julia should not be wise to start with v0.6.x, given the number of changes that happened between it and v1.0
As I said to a previous respondent, I have no truck with the progress made on upgrading packages to v1.0, I had always realised that this is not a trivial task, which was why v0.7 was muted as a medium term solution.
My article was about the information not being provided in allowing new users to find, select and use the Julia eco-system.
As a question, you say that a number of packages have been brought up to work with v1.0.x, which I’m sure is true, Can you give me some idea of the percentage and where I can get a definitive list?
It seems that you’re saying that it should be a bad idea to suggest v0.6, but given the ecosystem status that is what you’re inclined to do. Or am I misunderstanding you? What are the packages that makes you come to this judgement? It’s been a long time since key packages were not ready. You will probably find that some packages that worked on v0.6 will never get updated because the developers moved on somehow. That’ll always be true though. Some people are developing v1.0 packages now that might never work on v2.0 because they leave the ecosystem before that. Most packages are MIT licensed though, so it’s quite easy to fork and continue the developing if the package is important to someone.
Like the other people, it’s not clear to me what made you change your sentiment towards Julia. I was surprised by the julia v1.0 release as well, but I think it’s been for the better when we take everything into consideration.
I am not sure who suggested starting with 0.6, or how this came up.
I don’t think this question is well-defined, unless you clarify the universe of packages. Eg as it happens frequently with free software, some packages are apparently abandoned, some since 0.4-0.5, and (I guess) are unlikely to be updated to 1.0, unless someone steps in to do it.
All the packages I use on regular basis have been updated, most within a month of 1.0. Many have seen multiple (minor) releases since. I think that at this point it is safe to say that if a package has not been updated to 1.0, the chances of it happening are very slim. So in a certain sense, nearly 100% of the actively maintained packages are updated (by construction ).
This probably has to do with the fact that Julia is a relatively young language, and for some tasks solutions are WIP. That said, users who ask here or on other forums with a specific problem in mind usually get advice and suggestions.
I’ve not changed my sentiment to Julia, only a reluctance at present to talk about it to non-Julians.
The comment about v0.6 being dead was made to me, not by me, although I understand it; any companies using Julia in their Enterprise work will probably be best suited to shy away from v1.0 for the present time.
However given the number of changes catalogued in the Release Notes (and elsewhere) for v0.7/v1.0, I would not want to encourage new users to learn to write code radically different from that which would run on v1.0
An overall percentage isn’t meaningful because there is a long tail of packages which were used one time by one user (the package author), and those are the packages which generally get less maintenance. However, if you take a look at the 200 or 300 packages which have generally gotten the most use in the Julia v0.6 and v1.0 timeframe, I would be surprised if there are any that aren’t updated now. At least, I haven’t noticed any in a long time. So at this point, among the packages that most users actually install, close to 100% of packages work on v1.0. I say “close” because there might be one or two that aren’t, but I can’t name any package off the top of my head that hasn’t upgraded now that JuliaDB is done. Can you?
Well okay sure that’s probably the best example. But even then, most of the features supposedly work now:
I’m not sure I totally agree that a language launched in 2012 is such a young one but I do agree that it is and remains a WIP, as do all programming languages.
But my article is not about that. There is a requirement upon a young language, or otherwise, to attract and encourage new users and I, as a seasoned user, am afraid that this has not happened yet (?) with v1.0, which is why a took the time to draft the posting.
I am curious how you are measuring this.
I know these things are hard to quantify, but cf some Github statistics in the recent newsletter.
Actually Cxx.jl was my choice too and a spoke of it at Monday’s talk; the reason I had revoked at it was because I’m recently finished revising a chapter on connectivity and when back to see if, since tagged as updated to v1,0, it now worked.
As an aside I also looked at the HTTP.jl, for a coming chapter, and while the README suggests it does not compiy with v1.0, it installed (always a good thing) and worked sufficiently for my purposes.
I was amused (perhaps not the right word) that the TOP Machine Learning package from Julia Observer is Mocha,jl, which the github page explains has been retired. As I have said a couple of times I think JO fulfils a role, but is by no means the complete deal.
My concerns are also about quality of information on packages as well as quantity and I see nothing wrong with asking which packages work with 1.0, - as a percentage or otherwise, - isn’t that supposedly the purpose of NewPkgEval , and which I, as an attendee to the Hackathon in London, saw displaying embryonic information on August 12th?
I showed the graph you have included in my talk on Monday. Of course there is a lot of activity on github post-JulaiCon 2018 , version v1.0 was announced then with a fanfare and a lot of people downloaded packages.
But again this is activity not compliance - it is information on the latter which I would like to see being produced and presented.
I believe a some what flippantly added the epithet: Isn’t Data Science wonderful?
It was after all supposed to be a fun evening.
That is a mistake in the README. It actually only tests v1.0+ these days.
I put a PR in to fix the README:
I used to be in the “should have waited longer” camp - but I think the decision to release when they did has proven to be the right one. The core team has limited influence on package maintainers, who are all busy folks, so I’m glad the core team took the lead with releasing 1.0, which spurred a bunch of packages to update much more quickly than I think they would have done otherwise.