migration to package extensions

[cjdoris]

Closes #405.

We can hopefully remove all these strong dependencies.

• Dates
• Markdown: needed for interactive help (probably always loaded by Julia anyway)
• Pkg: removed juliacall.Pkg
• REPL: it is only imported when needed (i.e. when juliacall is loaded in an interactive Python session)
• Requires
• Serialization: this is needed by __reduce__ in jlwrap anyway (unless we load it on demand??)
• Tables

[hhaensel]

@cjdoris Do you want help for migration to package extensions?
If so, would you like to keep the package working for Julia versions < v"1.9" via Requires?
For Stipple.jl we have chosen that pathway.

[cjdoris]

@cjdoris Do you want help for migration to package extensions? If so, would you like to keep the package working for Julia versions < v"1.9" via Requires? For Stipple.jl we have chosen that pathway.

Maybe, though the only things remaining on the list are Dates and Tables.

I think Dates can't be removed because if you do pyconvert(Any, some_python_datetime) then we need it to be converted to a Julia DateTime and Dates won't necessarily be loaded if we make it a weak dependency.

I'm not sure about Tables. We use it in two places:

• The PyPandasDataFrame wrapper type. The Tables functionality here can definitely go into an extension.
• The pytable function. For this to go into an extension, we'd need to know that Tables is definitely already loaded before pytable(x) is called for any table x. I don't think we can guarantee this because a package can just provide its Tables-compatibility via an extension, so if we call pytable(::FooPackage.FooTable) then FooPackage is certainly loaded but Tables might not be. It also won't work if x is a named tuple of vectors or a vector of named tuples, which are both considered tables, unless we provide special handling for them. As a concrete case, if we moved the PyPandasDataFrame stuff into an extension as in the previous bullet point, then pytable(::PyPandasDataFrame) would stop working because Tables wouldn't be loaded.

So all in all I think there's no more to do on this.

[hhaensel]

Well, I think there is. There are three occurrences of @require which would all be replaced by package extensions. The content of the extensions will be precompiled while there is no precompilation happening when you rely on @requires. As said above, we have kept Require.jl in the package environment for compatibility but we only use it for Julia versions < v1.9.
From Julia 1.11 on we have the possibility of defining version-dependent Project.toml files so that Requrire.jl will no longer be used.

[cjdoris]

Yes you're right the current uses of @require can be migrated to extensions.

Didn't know about the upcoming version-dependent Project.toml, that's cool!