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

[Feature Request] Allow install device dependent package as dependency #798

Closed
Roger-luo opened this issue Oct 5, 2018 · 2 comments
Closed

Comments

@Roger-luo
Copy link

Roger-luo commented Oct 5, 2018

I tried to ask this in discourse and slack, but seems there is no solution for this feature at the moment.

I notice for packages like Flux.jl/Knet.jl etc. They provide functionality on CPU, but also available on GPU. It would be more convenient for package developers to add device dependent package (like CuArray) when it is available. (Since we don't want our user to care about what package they should install)

Moreover, currently, for those device dependent code, you have to copy the UUID everywhere like:

https://github.com/FluxML/Flux.jl/blob/73385b5dbd7c46dee13b71e8d543448ea6c58707/src/treelike.jl#L67

But with Pkg3, a simple workaround (like by detecting CUDA in the system) won't work, because when required condition is true and then use using CuArray will cause the Pkg a warning says you don't have this in the dependency.

I think simply add a device tag in Project.toml will solve this problem, so there won't be any error in Pkg while using CuArray and let another package to handle the dependency checking (e.g CUDAapi)

So the Project.toml may looks like:

[deps]
# some other deps

[device]
[device.cuda]
CuArrays = "3a865a2d-5b23-5a0f-bc46-62713ec82fae"

Or

[deps]
# some general deps
[deps.cuda]
# package require cuda

BTW, we can use a plugin to support the first syntax without changing stdlib in the main tree I guess.

@KristofferC
Copy link
Member

Just adding different packages based on availability of devices on the system feels fragile

I think this has sufficient overlap with #1085 to be closed.

@KristofferC
Copy link
Member

I meant #1285

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

2 participants