may I strongly suggest that the backend repository implement a system whereby it tries each submitted package on a vanilla julia 1.0 install, and if this submitted package fails with an error at pre-compilation time to tag it? upon third party Pkg.add(), the end user can then see an announcement “does not yet precompile under julia 1.0” and not install it unless an extra force flag is thrown.
a more sophisticated Pkg could ping the repository with the compilation success or failure upon first time compilation, making it easier for developers to get statistics on installation attempts (presumably reflecting interest) and installation successes/failure. of course, it should be possible to turn off this feature for privacy, e.g., with a file in ~/.julia.
it makes a bad impression to have so many failing packages. it makes julia look disorganized. this could help a little bit, probably with relatively little effort. it doesn’t even have to be upon submission. it could even happen every night, and the tag could be maintained on another server that the Pkg system knows about.
it’s a bandaid until a better auto-verification system appears that can deal with version numbers, unit tests, etc.
It is however a bit scary thing to go in and change peoples bounds and, if not done delicately, could upset people if their working package happens to get capped and no longer be installable.
I think the heuristic we have in that PR is pretty good though so hopefully it can deployed quite soon.
The up side of that idea is that it might trigger people to update their packages to 1, including other format changes that might be considered optional (to avoid the “threat” of an eventual capping).
although the version checks are nice, isn’t it sufficient that a package does not manage a precompile on a vanilla julia install? this is really easy to automate, too.
and it would trigger only the stricter 1.0 package manager.
and the capping would be soft only. end users can override it if absolutely necessary, although I cannot imagine who would ever want to do this on a package that does not even manage a precompile.
Would it be better to make this a warning, where the user can confirm that he/she wants to install the package? Making the package non-installable seems too strong. Perhaps a package doesn’t pass all tests at Julia 1.0, or some parts of the package don’t work well. But what if the package has a particular function that I need, that does work in Julia 1.0 and I don’t care about the rest?
Also, I guess dev is not affected, right? We should be able to dev incompatible packages.
can I emphasize that the point is not us, the quasi-regular users of julia; but the newbies that are trying out julia 1.0 for the first time. we really do not want to turn them off on day 0.
so, such features really need to be both on a friendly website and in the Pkg manager itself.
Since packages are very easy to create and register, it is inevitable that the package ecosystem will be littered with abandonware in the long run. This happens with many languages, and should not per se turn newbies away.
Also, keep in mind that we are in a transition period: maintainers may be committed to a package, but may just be too busy (possibly with other packages ) to fix everything instantly.
IMO a curated list of packages is the best solution:
forgive me, tamas, but I have to disagree. we should curate packages but we cannot rely on it on a continuous basis. we can detect continuously whether they pass minimal hurdles…such as succeed on pre-compilation.
But keep in mind that being able to compile a package does not say anything about its quality. Even if the unit tests run, that is only indicative of anything if they are well-designed and have good coverage. Ultimately, choosing a package is something that should be based on an (informal) evaluation of users experienced in a particular domain, and thus it is difficult to automate.
At this point in Julia’s history, we are in a position that not being able to compile a package is a strong signal of it being abandonned, since the language as been moving so fast. But this will not be the case as long as 1.x is around, as even total abandonware with a ton of bugs will precompile and load just fine if it did at any point.
very much agreed. the pre-compilation success is a minimal criterion (does not assure quality) and even the “ping at the end” are features that an intern can produce within a day, and make available tomorrow.
most importantly, they can make julia look much more polished at very little cost tomorrow and even better in two weeks.
in a year or so, the problem will be much less anyway, and better and more permanent solutions can be found.
).