Pkg.jl: Do not offer to autocomplete `] add` with _jll packages

[cossio]

For example, if I type

] add Cairo

and hit TAB, it offers to autocomplete to both Cairo and Cairo_jll. Since the later is not intended to be installed by typical users, perhaps it should not be offered as an autocomplete option. The _jll options pollute the autocomplete offerings.

If someone needs to install a _jll for some reason, they can always type it out.

[giordano]

Package developers will need to ]add a JLL package to their projects, removing them from the list of autocompleting packages would be a regression for those users.

[DilumAluthge]

Perhaps make it a configuration option? Certainly sounds like it will be annoying to users to have the JLL packages always come up in autocomplete. Would be simple to have a configuration option, maybe in your Julia startup file, to include JLL packages in the autocomplete lot.

[KristofferC]

I don't think many people will explicitly add jll packages. I think some custom handling for them in the status output and tab completions make sense.

[00vareladavid]

We could do something like pkg> add --jll Cairo which would add Cairo_jll

[ssfrr]

I don't know, I kind of like the fact that JLL packages are just regular Julia packages. It's cool that any user can easily pull in binary packages and start writing code that ccalls into them.

(edit: also it's nice that the same dependency mechanism to pull in dependencies works exactly the same for JLL packages. If they're special-cased in the pkg REPL would they be special-cased in Project.toml files as well?)

I'd suggest waiting it out to see if it's actually a problem in practice. It seems like it would be kind of finicky to decide which packages should be tab-completed, and not worth the confusion when you tab-complete and a package you expected to show up doesn't, because it was decided that it's not user-facing enough. For instance, most of the FooBase packages aren't really intended to be used by end-users, they're meant for other packages to depend on.

[KristofferC]

After using 1.3 for a while, yes, we need to do something about this. Having a huge number of

  [1082639a] + Xorg_libXext_jll v1.3.4+0
  [ea2f1a96] + Xorg_libXrender_jll v0.9.10+0
  [14d82f49] + Xorg_libpthread_stubs_jll v0.1.0+0
  [c7cfdc94] + Xorg_libxcb_jll v1.13.0+0
  [21e99dc2] + Xorg_renderproto_jll v0.11.1+0
  [7c09cfe3] + Xorg_util_macros_jll v1.19.2+0
  [c2e9c405] + Xorg_xcb_proto_jll v1.13.0+0
  [d13bc2ba] + Xorg_xextproto_jll v7.3.0+0

entries in your status output is frustrating.

These packages are not normal packages, they are automatically generated and does almost nothing (sets a few env variables and dlopens).

When adding a package adds 90 FooBase packages, we can talk about those as well

[ssfrr]

Yeah, as this has rolled out and users have been confused or frusturated I'm starting to see the logic of special-casing jll packages in the pkg REPL prompt. I don't really like the syntax of pkg> add --jll Cairo adding Cairo_jll, but I could see a --jll flag toggling whether _jll packages are displayed in output.

[StefanKarpinski]

Would export JULIA_PKG_SHOW_JLLS=true or something like that be too rudimentary, defaulting to off?

[fredrikekre]

Why not use -v/--verbose?

[StefanKarpinski]

Sure, that may be better.

[KristofferC]

You might want to be in a "jll mode" (when you are developing jll stuff) where you care about jll packages but perhaps don't want everything to be written verbosely. We could try with verbose for now and then add a jll mode if needed.

[rapus95]

I came here when searching for the artifact repl mode (seems like there is none, why?) and now I think as jll packages are always some sort of artifact/binary dependency how about introducing some new repl mode for handling those?

Then we have

• package mode: new functionality as julia code (jl)
• registry mode: (new) package lookup capabilities (lookup of jl & jll)
• binary/artifact mode: julia-external dependencies (jll)

Sure that's not an exact distinction since jll packages technically are standard julia packages, but I'd not compare them by capability but purpose. As they mostly consist of some sort of (auto-generated) glue code into some other environment, my understanding is that their purpose is to abstract some of the externals away (hide them behind julia variables/attributes and drag versioning into the Julia domain). Being normal packages just makes them being some sort of pimped externals abstraction in that sense that they can do arbitrary stuff.

Tl;Dr:
Regarding their purpose, artifacts & jll packages feel very similar. FWIW, adding a new artifact/binary repl mode to Pkg.jl where jll dependencies and artifacts can be managed would stop the pollution while grouping the external(=outside julia) dependency management utilities more logically + adding some interactive repl convenience for artifact management.