Changes between Version 25 and Version 26 of HackageToDo
- 07/25/07 17:58:17 (6 years ago)
v25 v26 7 7 8 8 Currently: 9 10 11 12 13 14 15 16 17 18 19 20 21 9 22 * [http://www.haskell.org/haddock/ Haddock] documentation for a library package is 10 23 placed in the directory ''archive''`/`''pkg''`/`''version''`/doc/html`. … … 12 25 to the documentation for the corresponding modules. 13 26 * The haddock documentation links to types, modules etc. in the packages it depends on. 14 * Links across packages always point to the latest version of the target package. 27 * Links across packages point to the latest version of the target package, unless 28 the dependency has a constraint that forbids this. 15 29 This way we don't have to worry about re-haddocking dependent packages whenever 16 30 a package at the bottom of the tree is updated. 17 Some dependencies may go wrong, if a package depends on a specific version of 18 another package for example, but this way is simple at least. 19 31 * The `--html-location` option of the development version of Cabal is used to make 20 32 haddock generate links pointing at ''archive''`/`''pkg''`/latest/doc/html`, 21 33 which will be a symbolic link to an `html` directory. 22 * Some trial runs have been made, generating documentation for some packages. 23 The missing part is automatic generation of the documentation. 24 Some possibilities: 25 * Avoid running arbitrary code to generate the Haddock by restricting ourselves 26 to packages that just use the simple build system and only Haddock those, then we don't 27 need to worry about arbitrary code. But some important packages use autoconf, and 28 we won't be able to do those. We could use the new `Build-Type` field to tell us 29 whether a package uses the simple build system or not. 30 * We could use Cabal to build the Haddock docs, but then prerequisite packages must be 31 configured, built, haddocked and installed (in a local package database), so we would 32 not be able to avoid running arbitrary code. 33 To be safe, this could be done in a chroot jail. 34 The latter choice seems cleanest. 34 * The build log for a package is placed in the file 35 ''archive''`/`''pkg''`/`''version''`/log`. 36 If this file exists, the package script displays a link to it. 35 37 36 38 Should building happen during upload, between upload and arriving in the archive, or later? … … 41 43 42 44 Other things we could do: 43 * Link to the build log from the package page. 44 45 * Generate a [http://www.haskell.org/hoogle Hoogle] database for searching. 45 46 * Syntax highlighted source code (using … … 54 55 There will be a need to add other attributes of uploaded packages, without modifying 55 56 the .cabal file. 56 This could be achieved with a plain text tags file, outside of the Cabal package, 57 providing a mapping from attributes to values (both strings). 57 This could be achieved by storing a mapping from attributes to values (both strings) outside of the Cabal package. 58 (Suggested format: a plain text file with a mail header format like the .cabal file.) 59 These attributes could be set by programs on the server, set by users via a web interface, shown by the package display and used for searching. 60 58 61 Example attributes: 59 62 * who uploaded the package … … 63 66 * user-supplied descriptions of the package 64 67 * feedback from users' [wiki:CabalInstall cabal-install] runs (?) 65 These attributes could be shown by the package display and used for searching. 68 * overriding fields from the .cabal file, e.g. `category` 66 69 67 The ycould also be used for a more sophisticated form of classification, 70 The could also be used for a more sophisticated form of classification, 68 71 as in [http://debtags.alioth.debian.org/ debtags], 69 72 but multiple categories should be enough for now.