Add path to errors

[magnusviri]

One thing I've noticed about making packages is that when there are errors it's hard to know exactly where I should go hacking. The reason why is because I know pkg does some magic when you cd to the pantry repo directory. So I'm just confused about what exactly is going on when it can't find things.

Here's some examples.

> pkg build khronos.org/opencl-icd-loader
error: Uncaught Error: Not in pantry: khronos.org∕opencl-headers

https://github.com/teaxyz/pantry#contributing
      throw new TeaError('not-found: pantry: package.yml', {project}, )
            ^
    at https://deno.land/x/libtea@v0.6.2/src/hooks/usePantry.ts:49:13
    at project (https://deno.land/x/libtea@v0.6.2/src/hooks/usePantry.ts:50:5)
    at Object.getDeps (file:///opt/tea/tea.xyz/brewkit/v0.44.1/lib/usePantry.ts:30:21)
    at file:///opt/tea/tea.xyz/brewkit/v0.44.1/libexec/sort.ts:24:29
    at ascend (https://deno.land/x/libtea@v0.6.2/src/plumbing/hydrate.ts:62:31)
    at ascend (https://deno.land/x/libtea@v0.6.2/src/plumbing/hydrate.ts:88:19)
    at eventLoopTick (ext:core/01_core.js:183:11)
    at async go (https://deno.land/x/libtea@v0.6.2/src/plumbing/hydrate.ts:93:5)
    at async hydrate (https://deno.land/x/libtea@v0.6.2/src/plumbing/hydrate.ts:102:7)
    at async file:///opt/tea/tea.xyz/brewkit/v0.44.1/libexec/sort.ts:23:13

I know why the above error is thrown. But it seems that sometimes if I build something locally that I don't get the error. It would be nice if the error told me the path of the pantry because I want to manually add the missing project so I can build the next one I'm working on.

Here's another example. I have no idea what this does, so I ran it to find out.

> pkg cellar -R
repairing: micro-editor.github.io
repairing: deno.land
repairing: deno.land
repairing: deno.land
repairing: deno.land
repairing: libpng.org
repairing: khronos.org/opencl-headers
repairing: zsh.sourceforge.io
repairing: pcre.org
repairing: pcre.org
error: Uncaught Error: not-found: pcre.org=2.0.0
      throw new Error(`not-found: ${pkgutils.str(installation.pkg)}`)
            ^
    at Object.resolve (https://deno.land/x/libtea@v0.6.2/src/hooks/useCellar.ts:78:13)
    at eventLoopTick (ext:core/01_core.js:183:11)
    at async link (https://deno.land/x/libtea@v0.6.2/src/plumbing/link.ts:9:24)

So something is broke with pcre.org. But I don't know which one, the main install or the repo. Well, I played with it and figured out it was the main install. But it would be nice if paths like this were printed.

[mxcl]

While I agree this could be better there isn't actually any options here.

There is one tea-prefix and one editable pantry (your clone). So if it's talking about a pantry it's your clone and if it's talking about installs it's in the prefix.

[mxcl]

I understand brewkit being scrappy is frustrating, but our resources are max’d out so we target the growth portions which is the tea/cli and the pantry. So brewkit is mainly just shit we throw together to make that work.

Here the error:

error: Uncaught Error: not-found: pcre.org=2.0.0
      throw new Error(`not-found: ${pkgutils.str(installation.pkg)}`)

Probably means that you have pcre.org/v2.0.0 installed or something. I dunno!

I know bad errors are frustrating. I spent literally weeks of time on brew to make them good. I have not yet had weeks of time to spend on that here. So they are often weird. Anticipating errors and their messages is often very unexpected. Any piece of code anywhere may throw an error from very deep in a stack of calls, so then when that error message finally is shown to the user it says “I error’d doing foo” and the user is “but I was doing bar wtf is foo?” and the only way to improve that is to anticipate it better in the code.

[mxcl]

Your request here seems simple right? That we show the path to the yaml for the project.

Well the code to read the pantry is abstracted so it doesn't know where the project file comes from. This makes various other parts simpler. Adding the path back in would mean passing around a larger object that knows that data, which complicates the rest of the code. So instead that data is lost because it only is needed for error situations.

Really I think the future is errors go through an AI that looks at the code and then analyzes what happened for you to give you more context. Until then these things typically are improved by iteration to some kind of v1.