Skip to content

avoid depending on heavily invalidating pacakges#3538

Open
KristofferC wants to merge 1 commit into
mainfrom
kc/avoid_inval
Open

avoid depending on heavily invalidating pacakges#3538
KristofferC wants to merge 1 commit into
mainfrom
kc/avoid_inval

Conversation

@KristofferC

Copy link
Copy Markdown
Member

These are not used in the package and should hence not be depended on. Adding heavily invalidating packages as dependencies kind of just "kicks the can down the road" and causes DataFrames to be unattractive to depend on.

Tagging some people who were active in #3285: @bkamins, @timholy, @quinnj, @nalimilan

These are not used in the package and should hence not be depended on
@bkamins

bkamins commented Jul 9, 2026

Copy link
Copy Markdown
Member

I am OK to proceed as @KristofferC proposes, but before moving forward a comment from other involved contributors is welcome.

@bkamins bkamins added the ecosystem Issues in DataFrames.jl ecosystem label Jul 9, 2026
@bkamins bkamins added this to the patch milestone Jul 9, 2026
@nalimilan

Copy link
Copy Markdown
Member

Would there be a way to store precompiled code for the extension so that no recompilation is needed after loading InlineStrings and SentinelArrays? For example, if we called include("src/precompile.jl") from the extension, would it store new versions of methods that are invalidated when loading it?

@quinnj

quinnj commented Jul 11, 2026

Copy link
Copy Markdown
Member

I echo @bkamins's question from the original issue/PR: should we instead focus on fixing the invalidations in these upstream packages? I'm happy to help push on that; I just wasn't aware of the issue or what is being measured exactly in calling them heavily invalidating packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ecosystem Issues in DataFrames.jl ecosystem

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants