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

Suggestion: Skip download of dependencies #1381

Closed
matthid opened this issue Jan 12, 2016 · 3 comments
Closed

Suggestion: Skip download of dependencies #1381

matthid opened this issue Jan 12, 2016 · 3 comments

Comments

@matthid
Copy link
Member

matthid commented Jan 12, 2016

Follow up of fsprojects/FSharp.Formatting#337.
I think the underlaying problem is that paket doesn't know that FAKE depends on FSharp.Compiler.Service. If it would, it could resolve compatible versions and the problem would no longer appear in the future.

On the other hand I can see that we don't want to download all of FAKEs dependencies, because they are already bundled (which is good)....

Would it make sense to either have a paket feature to specify 'light' dependencies on a nuget package (ie dependencies which are not downloaded on restore), possibly even outside of the regular nuget dependencies, for example as an additional file bundled in the nuget package?

Or maybe even easier: Specify the dependencies as usual in the nuspec and add a feature for paket to not download dependencies (if they are not required by other packages in the group). Something like

nuget FAKE restore: skipdependencies

Another idea would be to have this flag but packages can enable it by themself (for example by adding a special file to the nupkg or via nuspec metadata?), this would enable backwards compat with exisiting paket.dependencies.

What do you think?

@forki
Copy link
Member

forki commented Jan 12, 2016

I think this should all go into real nuget meta data.

That said: maybe we can still be smart here and special case fake inside of
paket or something like that
On Jan 12, 2016 11:15 PM, "Matthias Dittrich" [email protected]
wrote:

Follow up of fsprojects/FSharp.Formatting#337
fsprojects/FSharp.Formatting#337.
I think the underlaying problem is that paket doesn't know that FAKE
depends on FSharp.Compiler.Service. If it would, it could resolve
compatible versions and the problem would no longer appear in the future.

On the other hand I can see that we don't want to download all of FAKEs
dependencies, because they are already bundled (which is good)....

Would it make sense to either have a paket feature to specify 'light'
dependencies on a nuget package (ie dependencies which are not downloaded
on restore), possibly even outside of the regular nuget dependencies, for
example as an additional file bundled in the nuget package?

Or maybe even easier: Specify the dependencies as usual in the nuspec and
add a feature for paket to not download dependencies (if they are not
required by other packages in the group). Something like

nuget FAKE restore: skipdependencies

Another idea would be to have this flag but packages can enable it by
themself (for example by adding a special file to the nupkg or via nuspec
metadata?), this would enable backwards compat with exisiting
paket.dependencies.

What do you think?


Reply to this email directly or view it on GitHub
#1381.

@matthid
Copy link
Member Author

matthid commented Jan 13, 2016

Yeah that would probably work as well for most users.
Do you think about adding the dependencies to FAKE and add a special case in paket to skip the download or do you see a special case without modifying the FAKE package?

Thinking about the dependencies of FAKE they probably need to be "==" because even if paket could solve a ">=" or "<=" constraint, downloading it wouldn't really help (because the version is locked/bundled in FAKE).

@matthid
Copy link
Member Author

matthid commented May 26, 2017

I think netcore and FAKE 5 will solve this

@matthid matthid closed this as completed May 26, 2017
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