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.
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.
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.