Is working with private versions of Hackage supported/possible?

[adinapoli]

Hello all,

sorry if there is already a duplicated issue somewhere, weren't able to find it.

I am trying to port an existing project I have at work to use stack. The requisite is that I want to make this as less intrusive as possible, to try to convince later on the rest of the team to switch, proved stack is the correct tool for us. In doing so, I need stack to full interoperate with our private version of Hackage, which is hosted in a VPS and it's where we upload all our in-house, proprietary packages.

I have dutifully followed the FAQ, which suggest to add the package-indices section to my stack.yml, which now looks like this:

resolver: ghc-7.10
packages:
  - '.'
package-indices:
  - name: Our Private Hackage
    download-prefix: http://path-to-our-private-hackage/package/
    http: http://path-to-our-private-hackage/00-index.tar.gz
extra-deps: []

My expectation would be for stack to honour this and then bring "in scope" our in-house packages. But when I try to run stack build --flag chronos:development (incidentally is this the equivalent of calling cabal build -fdevelopment ?) I get (Sorry for the deluge of output!):

While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package MonadCatchIO-transformers in known packages

--  While attempting to add dependency,
    Could not find package aeson in known packages

--  While attempting to add dependency,
    Could not find package ansi-terminal in known packages

--  While attempting to add dependency,
    Could not find package api-tools in known packages

--  While attempting to add dependency,
    Could not find package async in known packages

--  While attempting to add dependency,
    Could not find package atlas in known packages

--  While attempting to add dependency,
    Could not find package attoparsec in known packages

--  While attempting to add dependency,
    Could not find package attoparsec-conduit in known packages

--  While attempting to add dependency,
    Could not find package blaze-builder in known packages

--  While attempting to add dependency,
    Could not find package blaze-html in known packages

--  While attempting to add dependency,
    Could not find package blaze-markup in known packages

--  While attempting to add dependency,
    Could not find package case-insensitive in known packages

--  Failure when adding dependencies:    
      MonadCatchIO-transformers: needed (>=0.3.0.0), but not present in build plan, latest is 0.3.1.3
      aeson: needed (>=0.6.2.0), but not present in build plan, latest is 0.9.0.1
      ansi-terminal: needed (>=0.6), but not present in build plan, latest is 0.6.2.1
      api-tools: needed (>=0.1.1), but not present in build plan, latest is 0.5.2
      async: needed (>=2.0.1.0), but not present in build plan, latest is 2.0.2
      atlas: needed (==1.0.9.3), but not present in build plan, latest is 1.0.11.0
      attoparsec: needed (>=0.10.4.0), but not present in build plan, latest is 0.13.0.0
      attoparsec-conduit: needed (>=1.0.1.2), but not present in build plan, latest is 1.1.0
      blaze-builder: needed (<0.4), but not present in build plan, latest is 0.4.0.1
      blaze-html: needed (>=0.6.1.1), but not present in build plan, latest is 0.8.0.2
      blaze-markup: needed (>=0.5.2.1), but not present in build plan, latest is 0.7.0.2
      case-insensitive: needed (>=1.1.0.3), but not present in build plan, latest is 1.2.0.4
      conduit: needed (>=1.0.8), but not present in build plan, latest is 1.2.4.2
      conduit-extra: needed (-any), but not present in build plan, latest is 1.1.9
      configurator: needed (>=0.2.0.2), but not present in build plan, latest is 0.3.0.0
      data-default: needed (>=0.5.3), but not present in build plan, latest is 0.5.3
      digestive-functors: needed (>=0.6.2.0), but not present in build plan, latest is 0.8.0.0
      digestive-functors-blaze: needed (>=0.6.0.2), but not present in build plan, latest is 0.6.0.6
      digestive-functors-heist: needed (>=0.8.4.0), but not present in build plan, latest is 0.8.6.2
      digestive-functors-snap: needed (>=0.6.0.1), but not present in build plan, latest is 0.6.1.3
      either: needed (>=4.0), but not present in build plan, latest is 4.4.1
      ekg: needed (>=0.3.1.3), but not present in build plan, latest is 0.4.0.6
      fay: needed (-any), but not present in build plan, latest is 0.23.1.6
      fay-jquery: needed (-any), but not present in build plan, latest is 0.6.0.3
      fay-text: needed (-any), but not present in build plan, latest is 0.3.2.2
      heist: needed (>=0.13 && <0.15), but not present in build plan, latest is 0.14.1
      hermes: needed (>=0.13.7.1 && <0.14.0.0), but not present in build plan, latest is 0.14.0.0
      http-conduit: needed (>=2.0.0.10), but not present in build plan, latest is 2.1.5
      http-types: needed (>=0.8.5), but not present in build plan, latest is 0.8.6
      lens: needed (<5.0), but not present in build plan, latest is 4.11
      map-syntax: needed (-any), but not present in build plan, latest is 0.2
      mtl: needed (>=2.1), but not present in build plan, latest is 2.2.1
      network: needed (>=2.4), but not present in build plan, latest is 2.6.2.0
      old-locale: needed (-any), but not present in build plan, latest is 1.0.0.7
      postmark: needed (>=0.1.1), but not present in build plan, latest is 0.1.1
      random: needed (>=1.0), but not present in build plan, latest is 1.1
      raw-strings-qq: needed (-any), but not present in build plan, latest is 1.0.2
      resourcet: needed (>=0.3), but not present in build plan, latest is 1.1.5
      safe: needed (>=0.3.3), but not present in build plan, latest is 0.3.9
      shelly: needed (>=1.5.2 && >=1.3.1), but not present in build plan, latest is 1.6.2.5
      snap: needed (>=0.13.0), but not present in build plan, latest is 0.14.0.5
      snap-core: needed (>=0.9.3), but not present in build plan, latest is 0.9.7.0
      snap-loader-dynamic: needed (>=0.10), but not present in build plan, latest is 0.10.0.3
      snap-loader-static: needed (>=0.9.0), but not present in build plan, latest is 0.9.0.2
      snap-server: needed (>=0.9.3), but not present in build plan, latest is 0.9.5.1
      snaplet-fay: needed (>=0.3.3.7), but not present in build plan, latest is 0.3.3.12
      snaplet-postgresql-simple: needed (>=0.5), but not present in build plan, latest is 0.6.0.2
      snaplet-purescript: needed (>=0.2.0.0), but not present in build plan, latest is 0.2.0.0
      text: needed (>=0.11 && >=0.11), but not present in build plan, latest is 1.2.1.1
      text-format: needed (>=0.3.1.0), but not present in build plan, latest is 0.3.1.1
      tls: needed (>=1.2.2), but not present in build plan, latest is 1.3.1
      unordered-containers: needed (>=0.2.3.3), but not present in build plan, latest is 0.2.5.1
      xmlhtml: needed (>=0.2.3), but not present in build plan, latest is 0.2.3.4
    needed for package: chronos-0.13.7.0

--  While attempting to add dependency,
    Could not find package conduit in known packages

--  While attempting to add dependency,
    Could not find package conduit-extra in known packages

--  While attempting to add dependency,
    Could not find package configurator in known packages

--  While attempting to add dependency,
    Could not find package data-default in known packages

--  While attempting to add dependency,
    Could not find package digestive-functors in known packages

--  While attempting to add dependency,
    Could not find package digestive-functors-blaze in known packages

--  While attempting to add dependency,
    Could not find package digestive-functors-heist in known packages

--  While attempting to add dependency,
    Could not find package digestive-functors-snap in known packages

--  While attempting to add dependency,
    Could not find package either in known packages

--  While attempting to add dependency,
    Could not find package ekg in known packages

--  While attempting to add dependency,
    Could not find package fay in known packages

--  While attempting to add dependency,
    Could not find package fay-jquery in known packages

--  While attempting to add dependency,
    Could not find package fay-text in known packages

--  While attempting to add dependency,
    Could not find package heist in known packages

--  While attempting to add dependency,
    Could not find package hermes in known packages

--  While attempting to add dependency,
    Could not find package http-conduit in known packages

--  While attempting to add dependency,
    Could not find package http-types in known packages

--  While attempting to add dependency,
    Could not find package lens in known packages

--  While attempting to add dependency,
    Could not find package map-syntax in known packages

--  While attempting to add dependency,
    Could not find package mtl in known packages

--  While attempting to add dependency,
    Could not find package network in known packages

--  While attempting to add dependency,
    Could not find package old-locale in known packages

--  While attempting to add dependency,
    Could not find package postmark in known packages

--  While attempting to add dependency,
    Could not find package random in known packages

--  While attempting to add dependency,
    Could not find package raw-strings-qq in known packages

--  While attempting to add dependency,
    Could not find package resourcet in known packages

--  While attempting to add dependency,
    Could not find package safe in known packages

--  While attempting to add dependency,
    Could not find package shelly in known packages

--  While attempting to add dependency,
    Could not find package snap in known packages

--  While attempting to add dependency,
    Could not find package snap-core in known packages

--  While attempting to add dependency,
    Could not find package snap-loader-dynamic in known packages

--  While attempting to add dependency,
    Could not find package snap-loader-static in known packages

--  While attempting to add dependency,
    Could not find package snap-server in known packages

--  While attempting to add dependency,
    Could not find package snaplet-fay in known packages

--  While attempting to add dependency,
    Could not find package snaplet-postgresql-simple in known packages

--  While attempting to add dependency,
    Could not find package snaplet-purescript in known packages

--  While attempting to add dependency,
    Could not find package text in known packages

--  While attempting to add dependency,
    Could not find package text-format in known packages

--  While attempting to add dependency,
    Could not find package tls in known packages

--  While attempting to add dependency,
    Could not find package unordered-containers in known packages

--  While attempting to add dependency,
    Could not find package xmlhtml in known packages

Recommended action: try adding the following to your extra-deps in /Users/adinapoli/work/chronos/stack.yaml
- MonadCatchIO-transformers-0.3.1.3
- aeson-0.9.0.1
- ansi-terminal-0.6.2.1
- api-tools-0.5.2
- async-2.0.2
- atlas-1.0.11.0
- attoparsec-0.13.0.0
- attoparsec-conduit-1.1.0
- blaze-builder-0.4.0.1
- blaze-html-0.8.0.2
- blaze-markup-0.7.0.2
- case-insensitive-1.2.0.4
- conduit-1.2.4.2
- conduit-extra-1.1.9
- configurator-0.3.0.0
- data-default-0.5.3
- digestive-functors-0.8.0.0
- digestive-functors-blaze-0.6.0.6
- digestive-functors-heist-0.8.6.2
- digestive-functors-snap-0.6.1.3
- either-4.4.1
- ekg-0.4.0.6
- fay-0.23.1.6
- fay-jquery-0.6.0.3
- fay-text-0.3.2.2
- heist-0.14.1
- hermes-0.14.0.0
- http-conduit-2.1.5
- http-types-0.8.6
- lens-4.11
- map-syntax-0.2
- mtl-2.2.1
- network-2.6.2.0
- old-locale-1.0.0.7
- postmark-0.1.1
- random-1.1
- raw-strings-qq-1.0.2
- resourcet-1.1.5
- safe-0.3.9
- shelly-1.6.2.5
- snap-0.14.0.5
- snap-core-0.9.7.0
- snap-loader-dynamic-0.10.0.3
- snap-loader-static-0.9.0.2
- snap-server-0.9.5.1
- snaplet-fay-0.3.3.12
- snaplet-postgresql-simple-0.6.0.2
- snaplet-purescript-0.2.0.0
- text-1.2.1.1
- text-format-0.3.1.1
- tls-1.3.1
- unordered-containers-0.2.5.1
- xmlhtml-0.2.3.4

You may also want to try the 'stack solver' command

I have also tried to run stack init --solver, but without much luck either:

☁  chronos [issue-448] ⚡ stack init --solver
Writing default config file to: /Users/adinapoli/work/chronos/stack.yaml
Basing on cabal files:
- /Users/adinapoli/work/chronos/chronos.cabal

Asking cabal to calculate a build plan, please wait
Running /usr/hs/bin/cabal --config-file=/var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/cabal-solver49779/cabal.config install -v --dry-run --only-dependencies --reorder-goals --max-backjumps=-1 --package-db=clear --package-db=global /Users/adinapoli/work/chronos/ exited with ExitFailure 1
/usr/hs/bin/alex --version
/Users/adinapoli/Library/Haskell/bin/cpphs --version
/usr/bin/gcc -dumpversion
/Users/adinapoli/.cabal/bin/ghcjs --numeric-ghcjs-version
/Users/adinapoli/.cabal/bin/ghcjs-pkg --ghcjs-version
/usr/hs/bin/haddock --version
/usr/hs/bin/happy --version
/usr/hs/bin/hpc version
looking for tool hsc2hs near compiler in /usr/hs/bin
found hsc2hs in /usr/hs/bin/hsc2hs
/usr/hs/bin/hsc2hs --version
/Users/adinapoli/.cabal/bin/HsColour -version
/usr/hs/bin/ghc -c /var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/49786.c -o /var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/49786.o
/usr/bin/ld -x -r /var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/49786.o -o /var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/49787.o
/usr/local/bin/pkg-config --version
Warning: cannot determine version of /usr/bin/strip :
""
/usr/bin/tar --help
Reading available packages...
Updating the index cache file...
Choosing modular solver.
Resolving dependencies...
cabal-1.22.0.1: Could not resolve dependencies:
trying: chronos-0.13.7.0 (user goal)
next goal: hermes (dependency of chronos-0.13.7.0)
Dependency tree exhaustively searched.
cabal --config-file=/var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/cabal-solver49779/cabal.config: /usr/hs/tools/cabal-1.22.0.1 failure (return code=1)

Here hermes is our proprietary package, available only on our private Hackage.

Any idea?

Thanks!
Alfredo

[snoyberg]

I think you need to add Hackage as well. The semantics of this are to replace previous package indices, not augment them, since you can always add in additional ones locally. Can you try doing that and see how it works?

[adinapoli]

Hey Micheal,

I think I was misleading my omitting a crucial fact: Our private Hackage faithfully mirrors the main Hackage, so virtually ALL the packages which are there, are also in our Hackage. On top of those, we have our extra in-house pkgs.

Said this, do you still want me to try adding the official Hackage as well? Just shout, it's really an easy thing to try on my side.

[snoyberg]

Never mind, I missed the end of your comment. Since you're using the ghc-7.10 resolver, you need to add all extra packages to your extra-deps. You can fix this by:

• Switching to a Stackage Nightly snapshot instead
• Using stack solver
• Try copying the extra-deps information from the end of the output to your stack.yaml

[adinapoli]

Ah, that's what I suspected. Replying by points:

1. This seems to prevent me to use GHC 7.10 and/or having finer-grain control over which version of GHC I want to use. Am I wrong? Furthermore, this will help me with the "standard" dependencies, but what about our in-house packages? Would that be fetched automatically from the package indices or the extra-deps curation is still needed?
2. I have tried running stack solver but it fails with the error attached at the end of the original comment
3. This might certainly work, but seems a bit too much of an overhead. I have started doing down this path, but stack was suggesting me to add dozens and dozens of packages. This chronos project features 371 packages in its database (I can imagine a couple are the same package but different version) and it seems a dealbreaker to have a gargantuan stack.yml with hundreds of package in there. What is worse is that this extra-deps would now need constant amending if I want to bump the packages as I do upgrades (it will resemble a sort of implicit cabal.config - the same you can obtain with a cabal freeze).

Are we out of other options here? What's the path of least resistance?

Thanks!
Alfredo

[snoyberg]

1. Not at all. Stackage Nightly is already on GHC 7.10. If you don't like some of the packages selected by Stackage Nightly, you can override their versions by extra-deps. For in-house dependencies, you would still need extra-deps
2. You may need to run stack update manually before stack init --solver. You can also try running stack solver now that you have a stack.yaml file
3. I agree that this isn't the right course, that's why I recommend using a snapshot. There's also the option of custom snapshots, which @feuerbach is working on.

[adinapoli]

Ah, thanks for clarifying!

I will have a play and I will get back to you, especially wrt 2) (I did try stack update but I did that after running stack init --solver, so perhaps that was my mistake).

Alfredo

[adinapoli]

Hey Michael,

it's me again (I hope these real world experience reports from the trenches are useful!).

After yesterday wrestling, this morning I had to split part of an in-house package into a small and specialised one, and I thought of giving stack another chance for the task at stake. This is my experience report:

I started with this innocent stack.yaml:

resolver: ghc-7.10
flags:
    atlas:
      library-only: true
packages:
  - '.'
package-indices:
  - name: Our Private Hackage
    download-prefix: http://our-private-hackage/package/
    http: http://our-private-hackage/00-index.tar.gz
extra-deps:
  - atlas-1.0.9.2
  - hermes-1.0.0.5

This didn't work out of the box, and stack was suggesting me to add dozens & dozens of packages in the extra-deps section, so I decided to fall back in using lts-2.16. With that things smoothed up a bit, but I had still to add lots of packages to the extra-deps section because the solver was not able to figure out things for me. I ended up with this behemoth:

resolver: lts-2.16
flags:
    atlas:
      library-only: true
    lifted-async:
      monad-control-1: false
packages:
  - '.'
package-indices:
  - name: Our Private Hackage
    download-prefix: http://our-private-hackage/package/
    http: http://our-private-hackage/00-index.tar.gz
extra-deps:
  - atlas-1.0.9.2
  - api-tools-0.5.2
  - hermes-1.0.0.5
  - acid-state-0.12.4
  - amqp-0.12
  - annotated-wl-pprint-0.6.0
  - api-tools-0.5.2
  - ekg-0.4.0.6
  - ekg-core-0.1.0.4
  - hackage-uploader-0.2.0.10
  - io-streams-1.3.1.0
  - ixset-typed-0.3
  - pbkdf-1.1.1.1
  - postgresql-simple-sop-0.1.0.7
  - regex-compat-tdfa-0.95.1.4
  - resource-pool-catchio-0.2.1.0
  - rncryptor-0.0.2.1
  - shelly-1.5.4.1
  - snap-cors-1.2.9
  - snap-loader-static-0.9.0.2
  - snaplet-acid-state-0.2.7
  - snaplet-postgresql-simple-0.6.0.2
  - statsd-datadog-0.2.0.0
  - string-conv-0.1
  - tasty-hspec-1.1
  - tasty-rerun-1.1.4
  - threads-supervisor-1.0.3.0
  - lens-4.3.3
  - text-1.1.1.3
  - primitive-0.5.4.0
  - safecopy-0.8.2
  - exceptions-0.6.1
  - monad-control-0.3.3.1
  - lifted-async-0.6.0.1
  - aeson-pretty-0.7
  - blaze-builder-0.3.3.4
  - blaze-builder-enumerator-0.2.0.6
  - blaze-html-0.7.1.0
  - blaze-markup-0.6.3.0
  - blaze-textual-0.2.0.9

After all of this, stack was able to execute stack build. This come with the additional pain of having to watch the solver fail because we are locking down some dependencies upstream (example - in our project we locked down amqp to 0.12 for various reasons, lts-2.16 had a more recent version, we had to amend extra-deps and so on...)

What I've liked

1. I really liked the fact you can specify upfront the flags the packages you are building needs to flip. To give an example, our atlas package can be build library only or as a full-fat client. Specifying library-only: true in the stack.yaml simply gives me peace of mind.
2. There is an explicit section for the extra-include-dirs and extra-lib-dirs.
3. As long as your packages are in the LTS and you do not have funky constrains, it just work, and if you stick with a lts for a while you are guaranteed the package versions will always be the same after each build.

What I've liked less

1. I would really like the package-indices section to somehow augment the selection of packages stack can build from. In the attached stack.yaml it's a shame I had to add so many of them, because they are not in the lts-2.16. It gets out of hand quite quickly.
2. At work we use a tool called hub (created by my colleague Chris Dornan during the early days, when no cabal sandboxing or cabal freeze was around) as a way to always have reproducible builds. Imagine hub like a way of doing global-level sandboxing where dependencies can be locked down by hub save into a manifest. Such manifest proved to be extremely handy for us as it describe explicitly all the dependencies my project depends on. Such manifest can be loaded with hub load and voila, you got reproducible, predictable builds. Additionally, this doesn't get in your way: You can still do a cabal install, leave the
   cabal solver do the heavy work, then dump the set of packages cabal choose to build into the manifest and you are good. You want to upgrade a library? You just do a new cabal install on the upgraded cabal project, save the resulting manifest are you are good to go. With stack, if I want to migrate an existing project, I would
   need to do (as the FAQ suggests): stack init --solver without having a stack.yaml in scope (or stack will refuse to continue), but yet the solver would fail because my in-house packages cannot be found (as no package-indices is still there), but if I create a barebone stack.yaml with a blank extra-deps and I run stack solver, it would choke after the first dependencies it cannot match:

Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Choosing modular solver.
Resolving dependencies...
cabal-1.22.0.1: Could not resolve dependencies:
trying: pan-0.1.0.0 (user goal)
next goal: safe (dependency of pan-0.1.0.0)
Dependency tree exhaustively searched.
cabal --config-file=/var/folders/js/cv_q5mqd6_g76353vq_n4nqc0000gn/T/cabal-solver57051/cabal.config: /usr/hs/tools/cabal-1.22.0.1 failure (return code=1)

After this, I would get a disheartened and decide to either go into the extra-deps route of just give up. If I had all the packages coming from my private hackage, I would expect this to just work.

All that say, please take this only as a genuine experience report from someone already using tools in his daily workflow, and trying stack for the first time - I think
all the work fpco and the other contributors are going is amazing!

TL;DR:

Generally speaking, if I needed to convince my team to switch to stack, I would have an hard time "selling" it (I know it's a terrible thing to say!), and the reason would be:

• We still want to have complete visibility over the packages we are installing, which
  means some sort of dump/manifest which would tell me all the packages I'm using
  their version. I guess the closest thing here is a cabal freeze dump
• We still want to use our private Hackage to not disrupt our flow, potentially ignoring altogether the lts story. We would like to simply specify in a stack.yaml
  "Use this version of GHC, but draws packages from this hackage server)
• We would like stack init --solver to generate for us an initial, coherent stack.yaml, with virtually no amending from our side, using our private hackage to bootstrap the solving.
• We would like somehow to not have the burden of maintaining 2 manifests: the normal .cabal file and the stack.yaml file. Ideally we would the latter (at least the extra-deps section) to be automatically (re)generated out from the packages we have currently installed for our project.

But where I can see stack really shine for shops like us is the deployment story. One big cons of hub is that you need to install it on each machine you want to deploy, then configure your project, load your package manifest and then install it. It can be quite cumbersome and a lot of work to deploy. Granted, you can still use Jenkins to build an rpm and deploy and executable, but that seems quite a bit of scaffolding anyway.

Conversely, stack is great as it fetches for you all you need given a pristine environment, and it doesn't clash with any existing installation. I have seen there are options for selecting the arch and the os, (I have yet to try them), but I really hope that in the future this will means I can say something like (on my Darwin machine) stack build --arch x86_64 --os linux and have stack cross-compile my project into a linux ELF I can then drag & drop and be done. I know all the story around GLIBC and whatnot, but I would be happy to have a command line flag to do the cross compilation on certain linux target platform, like linux-centos or linux-debian, so that the dynamic linking would just work.

Another big plus is the cached builds, which I still have to investigate, but if I
understood correctly you lose those if you are not using lts (as those package builds are cached on fpco's S3 buckets), am I right?

I think this ticket can be closed as the answer of that question is "Yes, it can be done, but it was a bit cumbersome for my (totally subjective) experience".

I also want to point out that perhaps all of this might be out of the scope of stack and the foundations stack was build on, but nevertheless I thought was worthwhile sharing.

Hope this piece of feedback will be useful to improve stack, and sorry if it was long-winded and confusing in more than one section!

Alfredo

[snoyberg]

My overall thought is: a lot of what you're trying to do is force cabal-centric workarounds into stack. stack really doesn't need to use a custom Hackage mirror to get extra packages, it has better ways of doing it (which aren't available in cabal-land). We never automatically grab packages from any package index, because that means the reproducibility of a build depends on what's in the upstream index, which leads to random build breakages, which is exactly what we're trying to avoid.

Based on this feedback and similar questions, Tristan will be writing up some documentation (see #489). For the sake of your own sanity in builds, I'd recommend thinking again about reproducible builds, it's one of the prime pain points in cabal and something we've designed from the start to work in stack.

[adinapoli]

Hey Michael,

thanks for replying. Yes, I'm now a couple of days into Stack and I can see where you are coming from. In my "defence" I think the cabal-centric approach stems as the result of trying to apply the past of least resistance when migrating and incorporate stack into the everyday workflow.

I can imagine there are others like me falling into the same pitfalls. Looking forward to reading such documentation!

[snoyberg]

Cool, glad to hear it! And the feedback here was helpful. Even if I'm stubbornly stick to my guns on stack being right here[1], it helps us to know what needs more clarification.

[1] Well, I hope I'm not really that stubborn

[adinapoli]

Glad it was useful, I wrote that with that ultimate purpose in mind! I really like where stack is going, I was just playing the devil's advocate, trying to anticipate any possible doubt/skepticism from the rest of my team 😉