Add section on inclusive/exclusive

Michael Snoyman 2014-08-25 00:06:03 -07:00
parent acf8b95388
commit c02c5e0082

@ -31,3 +31,25 @@ yet. There is
for this. Once it is addressed you'll be able to have a snapshot per
sandbox. Until then, you can either use a stackage globally, or embed
your sandbox inside hsenv.
# What's the difference between inclusive and exclusive snapshots?
Imagine that Hackage has the follow packages and versions:
* foo-1.0
* foo-1.1
* bar-1.0
* bar-1.1
And let's say that foo is in Stackage, but bar is not. Stackage will select (most likely) version 1.1 of foo, and confirm that it will compile and pass tests with all the other packages in in Stackage. Then, foo-1.1 will be included in the snapshot, both of inclusive and exclusive. foo-1.0 will not be included in either snapshot.
What about bar? Stackage can give no guarantees about *any* version of bar compiling and working with the rest of Stackage. So there are two choices:
* Don't include bar at all.
* Include *some* version- or many versions- of bar.
The first option is the safest: if a package is in the snapshot, you know it compiles. The second option introduces something quite arbitrary: *which* version of bar should we include? Arguably, the most sensible choice is "just include all versions of bar, and hope that cabal can figure it out."
The first option is our exclusive snapshots. The second option is our inclusive snapshots. The second option is useful when there are a number of packages not available in Stackage that you want to use, while still getting most of the benefits of Stackage.
But my real recommendation is: if you want to use a package not in the current Stackage snapshot, send a pull request, get it included, and then use the next exclusive snapshot that includes it.