Comments (4)
(Imported comment by @SyntaxPolice on 2005-12-08)
correspondence between isaac and krasimir:
2005/12/8, Isaac Jones <[email protected]>: > Krasimir Angelov <[email protected]> writes: > > > Hello Guys, > > > > I have started developing Shipments in Cabal. > > Awesome! FWIW, you should probably take a look at the package > dependency code in cabal-get, and you also might want to look at the > new cabal-install tool, as I expect that when we ship a cabal w/ > cabal-install, people will use it a lot. Although having shipments > makes cabal-install less important. > > The smarts in cabal-get is that it checks to see what's already > installed, and this might not really be desirable for a shipment > (unless we want to have a flag for only installing the necessary > stuff). > > BTW, could you open a new ticket or wiki page at the cabal wiki / > ticket tracker: > http://hackage.haskell.org/cgi-bin/trac/trac.cgi/report/3 Yes. I will. > > It is working like it was discussed previously. When there are > > multiple *.cabal files, in the directory where the Setup.lhs lies, > > then they all will be build in dependency order. > > Are you using a temporary package-conf file? It should but the dependency checking isn't implemented yet. > > In order to keep the backward compatibility the package description > > parser returns a list of PackageDescription. In the list there is > > one element for the library and one element for each executable. The > > package name for the executables is equal to the "executable" field > > in the corresponding stanza in the package description file. > > I see. You didn't want to break backward compatibility w/ the > PackageDescription type? The PackageDescription type is changed. The library and executables fields are removed. There is a new field content :: PackageContent. The PackageContent is something like: data PackageContent = Library { ..... } | Executable { .... } I just want keep backward compatibility in the package description file syntax. > I kinda like this, package.cabalship (or whatever) might look like: > > shipment: shipmentname > version: 1.1 -- inherited by the packages if they have no version num > copyright -- ditto > > The only down side I see to this is that if version can be in the > shipment, and need not be in the .cabal files, then the .cabal files > are no longer stand-alone (they need the shipment file). I would like to avoid the need for extra description files. The version and copyright fields doesn't make sense for me providing that each package has its own version, copyright, etc. > > b> In HSQL I am using package names like: hsql, hsql-odbc, hsql-mysql, ..... > > One solution is to use the common prefix in the package names as > > shipment name. When there is only one package, then the shipment name > > will be equal to the package name. The advantage is that, when the > > shipment name is encoded in the package name, then for the user it > > will be easier to find the package sources. > > The drawback is that we have to force some restriction on the package names. > > I don't really like the idea of forcing them to name their packages in > a particular way. For instance, you might have a package cabal but > want an executable install-cabal. We don't want to force people to > use particular names for their binaries. > > > c> Another solution is to use the name of the top level directory. The > > drawback is that the user can't rename the top level directory. > > Another simple idea is that we could add a shipment: field to the > .cabal file. This would cause some redundancy between .cabal files, > but that's nicer than b> or c>. I like the idea for "shipment" field since it is a light weight solution. The redundancy is not high and I can't see any reason why we shouldn't allow to have .cabal files from different shipments in one directory. In this case the sdist command will simply create multiple .tar.gz files. If the "shipment" field is missing then the default value will be equal to $pkgid. > Also, have you thought about how one might specify that they only want > to operate on one part of the package (a single .cabal file?). Maybe > defaultSetup could take optional command-line option which is the > .cabal file(s) to operate on, and if none are specified, then use > *.cabal. > > This is where the cabal-get dependency code could come in handy. > Let's say I have a shipment with A.cabal, B.cabal, and C.cabal where A > depends on B and B depends on C. I already have C installed for some > strange reason, it would be nice to say: > > ./setup configure A.cabal B.cabal > ./setup build > ./setup install > > and that should work just fine, because C is already installed. OTOH, > if you said: > > ./setup configure A.cabal > ./setup build > ./setup install > > then setup should complain that you don't have B. Yes. In Visual Haskell, I will need some way to specify that I want to build only one of the packages. Cheers, Krasimir
from cabal.
(Imported comment by @dcoutts on 2006-01-07)
I think the current consensus is that multi-package distributable units is not the way to go, but that we should make it easier for package developers to build a collection of related packages.
from cabal.
According to the discussion, this bug can be closed?
from cabal.
Yes, it's really really old.
from cabal.
Related Issues (20)
- Wrong condition for passing --working-dir flag HOT 9
- Weird solver behaviour: doesn't consider installed version first HOT 4
- Gotchas of `[TARGETS]`; implicit vs `all` vs combinations HOT 2
- Build failure with GHC-8.2 HOT 15
- How to alert users of known issues with released `cabal-install`? HOT 5
- Documentation for -fdeveloper HOT 3
- Assertion failure with `.tar.gz` file as package. HOT 3
- Incomprehensible "imported by" noise when package doesn't exist HOT 3
- `runhaskell Setup.hs configure --enable-split-sections` etc not documented online
- cabal says "does not match server, will redownload: file length mismatch" but does not redownload
- Disambiguate docs, `cabal` versus Cabal HOT 2
- Broken packages not detected by `ghc-pkg check` using Setup.hs (Gentoo Linux) HOT 2
- Unifying the various documentation flags under the `documentation:` stanza HOT 3
- Windows, foreign-library, Cabal-3.10.3.0 regression in linker HOT 2
- Fake package leaking when no `[TARGETS]`
- Make Setup a separate component
- Add support for logging handles in the Cabal library
- Hide cbits symbols via visibility attribute or compiler flag? HOT 1
- [Ubuntu] [3.12.0.0-prerelease] Semaphore does not exist HOT 9
- Split off `cabal get` command HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cabal.