Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

migration to package extensions #414

Draft
wants to merge 3 commits into
base: v1
Choose a base branch
from
Draft

migration to package extensions #414

wants to merge 3 commits into from

Conversation

cjdoris
Copy link
Collaborator

@cjdoris cjdoris commented Nov 6, 2023

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
Copy link

@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
Copy link
Collaborator Author

cjdoris commented Jun 19, 2024

@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
Copy link

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
Copy link
Collaborator Author

cjdoris commented Jun 20, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants