[opam-devel] OPAM 1.3 roadmap

Mon Feb 23 09:18:37 GMT 2015

On Mon, Feb 23, 2015 at 1:26 AM, Louis Gesbert <louis.gesbert at ocamlpro.com>
wrote:
> That's good to know. I have a question: do [Coq users] have, or at least
know about cygwin ? Does it scare them ?

The tech-savvy ones know about it, and I suspect that for the others we
could distribute it along with OPAM (as Jonathan Protzenko did in his
ocaml-on-windows installer) and they wouldn't mind.

Quoting here the message Jason Gross (definitely in the first category)
sent about OPAM+Coq's status on Windows.

Opam now seems to work fine for me, in that "opam install
> coq.8.4.dev+ltacprof" worked fine, and now "(eval `opam config env`;
> coqtop)" works fine and gives me the relevant coq version.  (I haven't
> figured out opam switches yet, though.)
> If I recall correctly, I downloaded the sources for opam 1.2.0 from
> http://opam.ocaml.org/doc/Install.html, and built it within cygwin.
>  (Again, I recall needing to do some PATH mangling, but I don't recall what
> I had to do in particular.  I may try to set up a VM and see if I can
> re-create the process, taking notes this time.)

It seems you're quite close, but "official" support and some documentation
would be very helpful.

>
>> - Gabriel Scherer, 21/02/2015 09:43 -
>> I'd like to add my voice in favor of Windows support -- I found that to
be
>> a more important issue when discussing with the Coq people and their use
of
>> OPAM. We in the OCaml community have been quite good at scaring away
>> Windows developers (and because it's mostly a crowd of software
developers
>> which often use other systems we didn't notice much), but the Coq
userbase
>> is much more diverse and contains non-programmers (or at least people
that
>> don't know they are programming), they do have Windows users.
>>
>> On Sat, Feb 21, 2015 at 9:37 AM, Simon Cruanes <
simon.cruanes.2007 at m4x.org>
>> wrote:
>>
>> > Sandboxing the build would also be a big security improvement. I think
>> > cabal now does it, and signing packages doesn't protect against
malicious
>> > or buggy packages (see: bumblebee's uninstall target). That also goes
hand
>> > in hand with file tracking. I don't know how difficult it is, though.
>> >
>> > Cheers!
>> >
>> > Le 21 février 2015 05:01:56 UTC+01:00, Louis Gesbert <
>> > louis.gesbert at ocamlpro.com> a écrit :
>> >>
>> >> With 1.2.1 almost out of the door, time has come to review the
roadmap discussed back in December and choose where we'll be going for 1.3.
Original mail attached for reference.
>> >>
>> >>
>> >> The topic that is burning hot at the moment is, specially after the
Debian Haskell build host has been compromised, security: we have no
signing at all at the moment, and we need to improve on this before it
becomes a problem. TUF [1] has devised a sane amount of rules for
repository management and signing that should make it easier to get it
right in OPAM. Hannes has mentionned writing an OCaml implementation for
TUF, which could get very helpful.
>> >>
>> >>
>> >> Also of importance is Windows support. It should at least be
straighforward and documented to get a basic Cygwin setup working. That
goes with adding automated tests (appveyor can now be added in Github
alongside Travis). Related is cleaning up external command usage (even if
not really justified by a Windows
>> >> port only, as David Allsopp pointed out) -- replacing curl calls by
cohttp, use ocaml-fileutils...
>> >>
>> >>
>> >> These are the other main features, that'll probably take more time if
we are to focus eg. on security:
>> >>
>> >> * a plugin mechanism with plugins for example for OCaml (for better
agnosticity), external dependency handling [2], documentation generation...
>> >>
>> >> * a 'provides:' field in OPAM files [3]. This is a loose requirement
if we want to switch the repository to have OCaml itself in a package
(which is already possible, but the system compiler may yet be an issue).
>> >>
>> >> * More flexible switch handling (multi-switch packages, per-switch
remotes, layered switches for cross-compilation...)
>> >>
>> >> * Tracking of files installed by packages. While unrelated to repo
signing, this might have some security implications, so we might want to
bring it in.
>> >>
>> >> * With file tracking, generating a binary repo (with some
limitations) could be quite
>> >> straight-forward.
>> >>
>> >>
>> >> Which of these do you think is most important ? Have I forgotten
anything ?
>> >>
>> >> Cheers,
>> >> Louis
>> >>
>> >>
>> >> [1] http://theupdateframework.com/
>> >> [2]
https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins
>> >> [3] https://github.com/ocaml/opam/blob/master/doc/design/provides.md
>> >>
>> >> message suivi
>> >> De :Louis Gesbert À :opam-devel at lists.ocaml.orgEnvoyé :Wed Dec 17
>> >> 11:07:40 UTC+01:00 2014Objet :[opam-devel] OPAM Roadmap -- what next ?
>> >>
>> >> Hi all,
>> >>
>> >>
>> >>
>> >> with some lag after the 1.2 release, I'd like to open some space for a
>> >> collective discussion of the priorities for where the energies should
go
>> >> next. We have mainly 3 directions for improvements: first,
portability,
>> >> with the main goal of a Windows version. Second, agnosticity, with
the goal
>> >> to make OPAM more generic, and try and open it to users outside of the
>> >> OCaml community (wouldn't OPAM for Haskell be fun ?). Third, there are
>> >> always lots of features and improvements that have been asked for, and
>> >> would improve the experience of current users.
>> >>
>> >>
>> >>
>> >> So here is a summary of what I've gathered. Feel free to add your own.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ## Portability
>> >>
>> >>
>> >>
>> >> - **Rewrite parallel command engine.** / done.
>> >>
>> >>
>> >>
>> >> - **Native system manipulation (cp, rm, curl...).**
>> >>
>> >> These are mostly done through calls to the shell or external programs.
>> >> It's
>> >>
>> >> not very pretty but quite pragmatic actually... until we want to run
on
>> >>
>> >> Windows without Cygwin. Anyway, this wouldn't be the end of
portability
>> >>
>> >> issues.
>> >>
>> >>
>> >>
>> >> - **Windows support.**
>> >>
>> >> for OPAM itself to begin with. This should be pretty close.
>> >>
>> >>
>> >>
>> >> - **Packages on Windows.**
>> >>
>> >> Locate common issues and attempt to find generic fixes.
>> >>
>> >>
>> >>
>> >> - Allow **direct use of more solvers** or solver servers.
>> >>
>> >>
>> >>
>> >> - **Support cross-compilation**
>> >>
>> >> This is quite an open issue at the moment.
>> >>
>> >>
>> >>
>> >> ## Agnosticity
>> >>
>> >>
>> >>
>> >> - **Isolate OCaml-specific stuff.**
>> >>
>> >> E.g. specific opam-file variables. See ocaml-specific.md
>> >>
>> >>
>> >>
>> >> - **Separate as plugins**
>> >>
>> >> To open the gate to OPAM without these plugins, or with other ones
>> >>
>> >>
>> >>
>> >> - **Compilers as packages.**
>> >>
>> >> This should mostly work now, but needs some tests and strengthening.
The
>> >> main
>> >>
>> >> thing still to do is to handle the system compiler changes properly ;
that
>> >>
>> >> part should be made more generic anyway (see discussion on hooks)
>> >>
>> >>
>> >>
>> >> ## Features
>> >>
>> >>
>> >>
>> >> - A **provides** field. Generally useful, but particulary so with
>> >>
>> >> compilers-as-packages
>> >>
>> >>
>> >>
>> >> - Releasing the **"features" field** for easier package configuration
>> >>
>> >>
>> >>
>> >> - **Track installed files**
>> >>
>> >>
>> >>
>> >> - **Improve security**: just checking md5s is quite light ; package
>> >> scripts can
>> >>
>> >> write anywhere
>> >>
>> >>
>> >>
>> >> - **OS-specific handling of dependencies** (eg dependencies on
packages
>> >> from the
>> >>
>> >> OS) with plugins (#1519)
>> >>
>> >>
>> >>
>> >> - Specify and implement **hooks**
>> >>
>> >>
>> >>
>> >> - Find a nicer way to **share dev repos** / undoable "pinning sources"
>> >>
>> >>
>> >>
>> >> - **Per-switch remotes**
>> >>
>> >>
>> >>
>> >> - **Multi-switch packages**
>> >>
>> >>
>> >>
>> >> - Support for (automatic generation of) **binary packages**
>> >>
>> >>
>> >>
>> >> - Nicer **ocamlfind interaction**
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Louis Gesbert
>> >>
>> >> ------------------------------
>> >>
>> >> opam-devel mailing list
>> >> opam-devel at lists.ocaml.org
>> >> http://lists.ocaml.org/listinfo/opam-devel
>> >>
>> >> ------------------------------
>> >>
>> >> opam-devel mailing list
>> >> opam-devel at lists.ocaml.org
>> >> http://lists.ocaml.org/listinfo/opam-devel
>> >>
>> >>
>> > --
>> > Simon
>> >
>> > _______________________________________________
>> > opam-devel mailing list
>> > opam-devel at lists.ocaml.org
>> > http://lists.ocaml.org/listinfo/opam-devel
>> >
>> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20150223/a95ccd9f/attachment.html>