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

making dependencies unconditional #170

Open
tpapp opened this issue Jul 22, 2019 · 3 comments
Open

making dependencies unconditional #170

tpapp opened this issue Jul 22, 2019 · 3 comments

Comments

@tpapp
Copy link
Collaborator

tpapp commented Jul 22, 2019

I am wondering if would make sense to simply depend on

  • Colors.jl,
  • DataFrames.jl,
  • Contour.jl,
  • Measurements.jl

instead of using Requires.@require. AFAIK these don't have binary dependencies (as opposed to eg Juno), so the cost is minor.

This would allow proper version management in Project.toml, and my understanding is that precompilation also works better if we do this.

@KristofferC
Copy link
Owner

Seems reasonable but it would be good to check how it impact load times.

@piever
Copy link

piever commented Sep 3, 2019

Just wanted to mention that if there is no problem to adding a default fallback, one could do

import Tables
TableData(x) = TableData(; Tables.columntable(x)...)

and support all table formats (e.g TypedTables, IndexedTables, StructArrays, Query iterators) with just a Tables dependency (which is a bit more lightweight than DataFrames). If the default fallback is excessive, one can check that Tables.istable(x) returns true.

@tpapp
Copy link
Collaborator Author

tpapp commented Sep 7, 2019

Yes, we should probably do that, and use Tables instead of DataFrame. Thanks for the suggestion.

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

No branches or pull requests

3 participants