That's good to know. I have a question: do they have, or at least know about cygwin ? Does it scare them ?
> - 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 <[email protected]> > 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 < > > [email protected]> 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 À :[email protected]é :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 > >> [email protected] > >> http://lists.ocaml.org/listinfo/opam-devel > >> > >> ------------------------------ > >> > >> opam-devel mailing list > >> [email protected] > >> http://lists.ocaml.org/listinfo/opam-devel > >> > >> > > -- > > Simon > > > > _______________________________________________ > > opam-devel mailing list > > [email protected] > > http://lists.ocaml.org/listinfo/opam-devel > > > > _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
