extern keyword (cf conditional modules)

[StefanKarpinski]

Implement the extern keyword as discussed here: #6884.

[tkelman]

thought this would have to be an 0.5 target, or am i not remembering the conversation on this right?

[StefanKarpinski]

It would be great but someone's got to do the work and I think it's a pretty short list of people who can.

[tkelman]

What about reserving the syntax as a no-op? Or will a macro in Compat be enough to let package authors start trying to use it once it gets implemented without breaking on past Julia versions?

[tkelman]

x-ref relevant discussion on the mailing list https://groups.google.com/d/msg/julia-users/RDTZnVbiBig/NfBTtodUBAAJ, particularly in how this needs to tie into precompilation

[tkelman]

This will be important to sit down and hammer out an implementation plan after #265 and the type system revamp (#8974) are finished.

[JeffBezanson]

@StefanKarpinski , @vtjnash and I discussed this and decided this is probably more complex and difficult than conditional loading, and perhaps beyond what is really needed. We kicked around the following idea:

• Code for bridging packages, like Gadfly-DataFrames, is conceptually a separate top-level package. For example many linux distros have packages like "python-zmq".
• Packages could be able to provide multiple modules, loadable via e.g. using Gadfly/DataFramesBridge. That would look in the Gadfly package directory, but for a different source file.
• There is a mechanism to automatically load such packages, e.g. according to a naming convention.

[iamed2]

Multiple modules for packages sounds great!

A concern: what happens with optional modules which have their own version requirements? (e.g., if Gadfly/DataFramesBridge requires DataFrames >= v"0.6.0")

[StefanKarpinski]

You basically just need to be able to declare what versions of "optional dependencies" each package can work with. In other words, effectively like having OPTIONAL with the same format as REQUIRE but instead of forcing installation of those packages, it's a constraint on their version only if they're also installed.

[tkelman]

Would it be an active constraint or a passive one? Would it be allowed to participate in version resolution, or only be allowed to disable the optional component when its bounds aren't met?

Would optional dependencies ever depend on multiple packages? Would these internal submodules be able to be nested?

[JeffBezanson]

I don't think we'll need nesting.

[tkelman]

closing this one then as we're back to preferring #6195

[lobingera]

@tkelman

as we're back to preferring #6195

Is there a document/blog anywhere describing the situation and the reason for that?

[tkelman]

We should have discussed more publically, some of the back and forth happened in person in Boston and I wasn't there either. I think the basic summary is that this would be harder to get right than the conditional modules version. Modules are the unit of precompilation today, conditional modules would be similar to Requires.jl but implemented in a way that correctly hooked into the precompilation mechanism. Or put another way, it would put some sugar / automation around the current option that already works of moving code that depends on A and B to a separate package C that unconditionally depends on both. Conditional modules would let you put the code for C inside one of A or B and automatically act like a separately precompiled package if the other is present at load time. It would have to correctly track the precompilation state to avoid the errors / missing functionality you get today with the hacky approximations of this, when the packages available at precompilation time differ from what's available at load time.