# Pkg offerings

**URL:** <https://discourse.julialang.org/t/pkg-offerings/14583>\
**Category:** Internals & Design\
**Created:** [September 5, 2018, 2:59pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583 "2018-09-05T14:59:54Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 5, 2018, 2:59pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/1 "2018-09-05T14:59:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 5, 2018, 3:04pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/2 "2018-09-05T15:04:07Z")

</div>

One plan is to have some heuristic to cap packages (make them non-installable) that are very likely not to work on 1.0 ([cap julia version for probably-0.7-incompatible packages by StefanKarpinski · Pull Request #685 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/pull/685)).

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.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [September 5, 2018, 3:49pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/3 "2018-09-05T15:49:48Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 5, 2018, 4:04pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/4 "2018-09-05T16:04:28Z")

</div>

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.

/iaw

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [September 5, 2018, 4:11pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/5 "2018-09-05T16:11:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 5, 2018, 4:14pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/6 "2018-09-05T16:14:04Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 5, 2018, 4:26pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/7 "2018-09-05T16:26:33Z")

</div>

> [@e3c6](#):
>
> 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?

You can always `dev Package` to get it anyway (and upgrade it to 1.0 🙂 ).

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

> <https://gist.github.com/KristofferC/6ef88542178e143fa9dc840fc1e13749>

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](https://github.com/JuliaLang/Pkg.jl/pull/685#issue-210357043).

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [September 5, 2018, 4:40pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/8 "2018-09-05T16:40:43Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 5, 2018, 5:18pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/9 "2018-09-05T17:18:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [September 5, 2018, 6:10pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/10 "2018-09-05T18:10:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 5, 2018, 6:43pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/11 "2018-09-05T18:43:50Z")

</div>

> [@e3c6](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![felipenoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/felipenoris/32/553_2.png) [@felipenoris](https://discourse.julialang.org/u/felipenoris)\
**Post date:** [September 6, 2018, 1:08am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/12 "2018-09-06T01:08:47Z")

</div>

btw, what happened to the [pkg.julialang.org](http://pkg.julialang.org) “test pass” badge? That was quite useful.

---

<div class="post-metadata">

**Author:** ![Ralph\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ralph_smith/32/10344_2.png) [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)\
**Post date:** [September 6, 2018, 2:47am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/13 "2018-09-06T02:47:51Z")

</div>

> [@kristoffer.carlsson](#):
>
> Would be interesting if there are packages in that list that people are actually using on 1.0.

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

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 6, 2018, 4:12am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/14 "2018-09-06T04:12:34Z")

</div>

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… 😉

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 6, 2018, 5:19am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/15 "2018-09-06T05:19:03Z")

</div>

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:

> **[GitHub - svaksha/Julia.jl: Curated decibans of Julia programming language.](https://github.com/svaksha/Julia.jl)**
>
> Curated decibans of Julia programming language. Contribute to svaksha/Julia.jl development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 6, 2018, 5:29am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/16 "2018-09-06T05:29:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 6, 2018, 5:37am UTC](https://discourse.julialang.org/t/pkg-offerings/14583/17 "2018-09-06T05:37:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 6, 2018, 1:50pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/18 "2018-09-06T13:50:26Z")

</div>

> [@Ralph\_Smith](#):
>
> There are some embarrassing entries (BinaryBuilder!) and some dependencies of several robustly updated packages (e.g. Graphics).

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.

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [September 6, 2018, 2:41pm UTC](https://discourse.julialang.org/t/pkg-offerings/14583/19 "2018-09-06T14:41:49Z")

</div>

> [@Tamas\_Papp](#):
>
> I think the two approaches are complementary.

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.