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

[OPAM] 2.0 #1

Closed
4 of 9 tasks
GemmaG opened this issue Aug 22, 2016 · 2 comments
Closed
4 of 9 tasks

[OPAM] 2.0 #1

GemmaG opened this issue Aug 22, 2016 · 2 comments

Comments

@GemmaG
Copy link
Contributor

GemmaG commented Aug 22, 2016

Based on (#2580)

  • do not force tests of recursive dependencies (related to (#2277) and (#2190))
  • integrated documentation. Need state update hooks or persistent event stream.
  • incremental builds: (#2596) described something very useful to speed-up incremental rebuild of pinned packages (that we can really use with local switches + local package rebuild commands to have a nice dev workflow)
    • local switches (related to (#1595))
  • better opam query
  • bundle/snapshot (related to (#929 and existing hacks)
  • local packages
  • bundles
  • more variables exposing OS constraints. See comment
@GemmaG GemmaG added this to the ICFP pre-release milestone Aug 22, 2016
@GemmaG GemmaG changed the title OPAM 2.0 [OPAM] 2.0 Aug 23, 2016
@GemmaG GemmaG removed this from the ICFP pre-release milestone Sep 14, 2016
@AltGr
Copy link

AltGr commented Sep 15, 2016

Seems I don't have the credentials to tick the boxes, but I think 1., 3., 3.1. and 4. can be considered done.

  1. Done
  2. needs some design, should be straightforward once the interface is decided. In the meantime, can probably be prototyped using the existing hooks.
  3. Done
    1. Done
  4. Done (well depends what the reference for "better" is, but it should be pretty flexible now; the beta period is exactly when specific missing parts should be pointed out, if any.)
  5. Deployment bundles are planned, but that will probably be for 2.1
  6. There is some support for local packages through --inplace-build; the rest is just query stuff or sugar over automatically pinning the package then installing with that option, so my opinion is that the bricks to allow experiments and designing the new workflows are here, and we can refine the interface over the beta period or for the next version
  7. Reproducible switches: export files do part of the job; @dbuenzli's proposal is also close to this. This is really orthogonal to the rest of the features (except maybe binary/deployment bundles) and needs some more design discussions, and once we have a format we should commit to it long-term, so I wouldn't rush it.
  8. Variables exposing OS constraints: provided there is a simple way to get the values of these variables, they can now be defined through global configuration. This is mostly a matter of choosing what needs to be defined.

@GemmaG
Copy link
Contributor Author

GemmaG commented Sep 15, 2016

I've given you write access now @AltGr - thanks!

@GemmaG GemmaG closed this as completed Oct 11, 2016
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

2 participants