Pkg offerings

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.

1 Like

One plan is to have some heuristic to cap packages (make them non-installable) that are very likely not to work on 1.0 (

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.


1 Like

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.

Q; if one function in a package compile fails, are the other functions still accessible?? I thought it just aborts.

A confirm is ok, but the default really should be “don’t install.”

more important, I think we need this sooner rather than later, now that newbies are flocking in…

You can always dev Package to get it anyway (and upgrade it to 1.0 :slight_smile: ).

For reference, with the heuristic in that PR, the following packages would not be installable using add Package on 0.7+.

Would be interesting if there are packages in that list that people are actually using on 1.0.

The heuristic is given in cap julia version for probably-0.7-incompatible packages by StefanKarpinski · Pull Request #685 · JuliaLang/Pkg.jl · GitHub.

1 Like

Still, an explanatory confirmation warning where the user still has the option to install anyway would be safer.

1 Like

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.


An explanatory warning should be enough to alert novice users. I don’t think it’s necessary to completely disable installation.

It is unlikely that we will do a warning style. If the package works, it shouldn’t be upper bounded and if it doesn’t work it should.


btw, what happened to the “test pass” badge? That was quite useful.

1 Like

There are some embarrassing entries (BinaryBuilder!) and some dependencies of several robustly updated packages (e.g. Graphics).

can I put another plug in here for a “ping” to a URL upon successful or unsuccessful first-time precompile?

it would be really ueful to know what is really useful… :wink:

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 :wink:) 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.


I think the two approaches are complementary.

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.


Thanks. Seems the problem is that the script looks for 0.7 entries in REQUIRE and thus misses julia 0.7.0-rc3 that e.g. BinaryBuilder has.

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.