-
Notifications
You must be signed in to change notification settings - Fork 644
Egg #7: The Idris Package Manager
Although, Idris can install packages, one of the ‘Dragons in the room’ has been the lack of a package manager. Given that this is no small task I have created this feature proposal to help guide the discussion and present a sorting house’ of requirements and ideas.
Thus we as a community can establish here the requirements and topics for discussion for an Idris Package Manager. The idea being that for each ‘issue’ presented a corresponding issue on the issue tracker can be added to discuss and track its progress. Some of these topics may already have corresponding issues on the issue tracker. Please go there for discussion. I have also added leading questions to help facilitate discussion under these topics.
- What information should be stored within the ‘iPKG’ files? Currently the format stores: a module index, source directory, executable information, main module, build options, binding information.
- Is the current format acceptable, or should a another configuration format be used?
Format can be discussed at Issue #1825
- Should a centralised system be used?
- How is this system to be realised?
- How is this system to be verified?
- What is the workflow for package submission?
- Should we wait until modules have been properly implemented.
- How to deal with multiple versions of packages?
Dependancy management can be discussed at Issue #1832
- What should the lib directory look like?
- Should idrisdoc be built and installed.
- Regardless of sub-commands or separate executable what is the expected behaviour of Idris w.r.t. to packages. Currently there is support for: install, build doc, check, clean, and build packages.
- Should the package manager handle executables?
- What do we call this?
- How much of this can we write in Idris instead of Haskell?
- Should SHA-3 Hashes be generated to track consistency of package uploads.
- Should we request that packages be signed as well?
I (shlevy) am a contributor to nixpkgs/NixOS, and I have some properties I would like to see in a language-specific package manager to enable easy incorporation into a more general framework:
- A clean library interface to all of the underlying stages of installation (ipkg parsing, dependency resolution, fetching, building, installing, etc.).
- A well-supported “offline” mode, where the source is already downloaded and the build/install works locally
- Support for arbitrary installation locations.
- Support for arbitrary dependency locations. Ideally it would be possible to specify multiple dependency locations for different dependencies.
- Support for declaring dependencies on non-Idris libraries, programs, etc. The Idris package manager itself may not be able to resolve (or even check) those, but if the ability is there and especially if people settle on conventions for how they refer to their libraries (e.g. curses vs ncurses vs something else?) then it will be much easier to ensure those are available.
- If there is to be a hackage-like central server, it would be nice if there were some quick-to-download metadata that included name, version, and hash (sha256 would be desirable for nixpkgs specifically).
Binary Packages
Tool Support
Community
- Libraries, available elsewhere
- Idris Developer Meetings
- The Zen of Idris
- Non English Resources
Development