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

Allow to pull extra-deps from other resolvers #1175

Closed
zudov opened this issue Oct 16, 2015 · 6 comments
Closed

Allow to pull extra-deps from other resolvers #1175

zudov opened this issue Oct 16, 2015 · 6 comments

Comments

@zudov
Copy link
Contributor

zudov commented Oct 16, 2015

It's often that a project uses an resolver x but also needs some dependencies which aren't in the x (but are in the y, or z). At the moment the only option is to just specify it in extra-deps with an explicit version. It would be nice if it was possible to pull them from some other resolver.

This syntax comes to mind (and would probably explain the intention better than text above):

- resolver: lts-3.9
- deps:
  - extra: # same as current `extra-deps`
    - package-which-isnt-present-in-any-of-resolvers-0.1.2.3
  - nightly-2015-10-16:
    - package-which-is-present-in-nightly

package-which-is-present-in-nightly doesn't need to contain an explicit version, it would just pick up the one from nightly-2015-10-16.

@borsboom
Copy link
Contributor

I'm a bit unclear on what concrete benefit this would really provide. Is it so hard to provide the exact version number in this case?

@zudov
Copy link
Contributor Author

zudov commented Oct 22, 2015

Let's imagine a situation where we use lts resolver, but want some other dependencies which are not present in lts but are in the nightly. Currently we end up with something like that:

extra-deps:
  - distributed-process-0.5.5.1
  - distributed-process-async-0.2.2
  - distributed-process-client-server-0.1.3.1
  - distributed-process-execution-0.1.2.1
  - ... many more

When I add those extra-deps, I don't have much guarantees that they would work fine with my project. However, if I pick the same versions as in the latest nightly release I can get the guarantee that they would at least compile against each other. So for every item in extra-deps I have to (1) check the version in some nightly release; (2) put that version in my extra-deps. I'd much rather just write:

- deps:
  - nightly-2015-10-16:
    - distributed-process
    - distributed-process-async
    - distributed-process-client-server
    - distributed-process-execution
    - ...many more

Now, let's imagine that some time passed and I want to bump these versions. Again I would have to open the stackage page of the latest resolver and check a version of every package that I have in my extra-deps. I would much rather prefer to do:

-    - nightly-2015-10-16
+    - nightly-2015-10-22

@zudov
Copy link
Contributor Author

zudov commented Oct 22, 2015

@borsboom So, answering your question.

It's not hard to provide the exact version number. But if you have more than a few dependencies and want them to be of the same versions as in some nightly it becomes repetitive and error-prone work which could be easily automatized, and I don't see any downsides of such feature (please tell me if you do).

@mgsloan
Copy link
Contributor

mgsloan commented Oct 22, 2015

The main downside I can think of for this is just that it's added code / configuration complexity.

Extensible snapshots seem to be related: #863

I'm on the wall about whether we should have something like this, but maybe it could be part of snapshot extension.

@borsboom
Copy link
Contributor

borsboom commented Nov 1, 2015

Related: #1265 (Unify extra-deps and extensible snapshots)

@mgsloan mgsloan added this to the P3: Optional milestone Nov 5, 2015
@mgsloan
Copy link
Contributor

mgsloan commented Mar 17, 2017

I don't think this is going to be implemented, closing.

@mgsloan mgsloan closed this as completed Mar 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants