Re: Cabal File Pretty Printer
Hi, Johan Tibell wrote: If we could encode a style guide in a formatter, it would be much easier for us to do automatic rewriting of Cabal files, which is needed for features like `cabal freeze` Many cabal files are generated by `cabal init`, which uses a consistent style that is different from the styles proposed in this thread. If the pretty printer is to encode a style guide that people are supposed to follow, I think the following would make sense: 1. change `cabal init` to use the pretty printer. 2. expose the pretty printer at the command line. Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: cabal install --only
Hi, Mikhail Glushenkov wrote: What is the purpose of the install command's --only flag? The documentation says Only installs the package in the current directory, but this is already supported by running cabal install in the current directory without arguments. Before installing the package in the current directory, cabal install resolves, downloads, builds and installs dependencies. So cabal install is not at all the same as cabal install --only. Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Package logo's
Hi, Bas van Dijk wrote: Tillmann Rendel wrote: Wouldn't it be more in line with the rest of the cabal infrastructure to specify the logo file in the cabal file, similar to, e.g., the license file? Yes it would be more in line. But apart from that, what advantage would it have? I see this generally about explicit configuration vs. naming conventions. Naming conventions are seemingly more modular: Old versions or unrelated components of the Cabal infrastructure and even third-party tools will automatically ignore the logo file. However, this modularity comes at a price: Different components or tools might disagree on the meaning of a naming convention. For different versions or components of the Cabal infrastructure, this can be avoided with some global namespace management for the naming convention. It can not be avoided, however, when third-party tools are involved. I think a Cabal package should be able to co-exist with another build or package system in the same directory. But if Cabal treats logo.png specially, and the other system treats logo.png specially in some other way, Cabal and the other system can no longer coexist. Downwards-compatibility is an instance of this effect. Naming conventions are both more downwards compatible (because old versions just ignore the logo file) and less downwards compatible (because new versions possible break old packages where logo.png is not meant to be a logo). Naming conventions can be more user-friendly, because the obvious thing just works, and no changes to the cabal file are necessary. However, explicit configuration can make it easier to discover features. For example, cabal-init could create -- Logo-file: ... in the cabal file, but it probably should not create a default logo file in the file system. (Or should it?). Naming conventions can be more or less efficient to implement. Consider the question: Which packages have logo files?. With a naming convention, this question can be answered for a single package by checking the file system, without reading and parsing any files. But with explicit configuration, this can be answered for all of hackage by just looking at the index, without unpacking any package tarballs. I see many good reasons for both naming conventions and explicit configuration. I just wonder whether it is a good idea to switch from one to the other in the middle of Cabal's success story. Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Package logo's
Hi, Bas van Dijk wrote: If a package has a logo.svg or logo.png file (all lower-case) in their package root then that logo is shown on the package page. SVG takes preference over PNG. Wouldn't it be more in line with the rest of the cabal infrastructure to specify the logo file in the cabal file, similar to, e.g., the license file? Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Proposal: Add a benchmark section to .cabal files
Hi, Johan Tibell wrote: [...] I'm convinced we need support for building benchmark using Cabal. [...] Could test sections be used for benchmarks, too? Step 1. Add basic support for building simple benchmark suites e.g. modelled after test suite sections: This should work immediately. Step 2. Add a detailed benchmark interface that allows the benchmark to associate a real valued *measure* (optionally with upper and lower bounds) with a benchmark name. This could be supported by a protocol where a test reports a real instead of a boolean value. Test bench-foo type: benchmark-1.0 main-is:bench-foo.hs build-depends: base Except for the more specialized keywords, there seems to be no need to distinguish tests from benchmarks. Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: hackage-server: index format
Hi, Matthew Gruen wrote: How would this interact with the absence of symlinks on Windows? Since the index tarball is never unpacked on the client's filesystem, only cabal needs to know about it, and it is backwards/forwards compatible. What's the benefit of using a tarball then, if some developers wouldn't be able to reasonably untar it. Duncan proposed to use tarballs with symlinks to structure local build trees, and if one can untar the tarball to get actual symlinks, this sounds great. One could have all kinds of intermediate layouts by putting partly symlinks and partly cabal files into the file system, or the tarball, or both. But I fear that on Windows, this would not work (or at the very least cause great troubles), so this seems to be an unnecessarily introduced platform dependency. Some kind of index file in a text format like Antoine proposes would be much more portable, and nearly as useful. Lars Viklund wrote: Note that NTFS has supported all kinds of links, sym- and hard-, since Vista and up, so I guess you're referring to exotic filesystems like FAT32, or slow-to-adopt environments. I refer to my experience that a symlink created by cygwin only works for cygwin-mediated filesystem access but not for filesystem access through the native Windows API. Therefore, I would not expect to be able to tar -xzf a symlink-containing tarball with my cygwin tar, and follow the link in the Windows explorer, say, or the file open dialog of my Windows editor. (I was not aware that NFTS supports symlinks, though. How would I access this feature on a Windows machine?) Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: hackage-server: index format
Duncan Coutts wrote: [...] symlinks [...] Opinions? How would this interact with the absence of symlinks on Windows? Tillmann ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
