bleep import fails unexpectedly about bleep

[oyvindberg]

Did you git clone --recurse-submodules ... ?

[oyvindberg]

Hey there, thanks for you interest in looking into it! :)

No there isn't I guess, except for this section in the readme. The way I see it, bleep is a normal JVM program. Of course it manages a bloop server which complicates things, and it's ultimately compiled to a graalvm image but you can typically ignore that.

So how to start then? mount the bleep codebase in your IDE like intellij, and start bleep.Main. set current working directory (in intellij run config or by adding a parameter -d ../some/other/dir). Then start it in debug mode and set breakpoints, and you should hopefully be able to navigate from there.

So in this case I think the problem looks somewhat obvious, the import code tries to read all generated source and resourcesfiles as UTF-8 encoded strings. if you have an sbt plugin which generates binary files, or at least non-UTF-8 encoded text files, this seems likely to blow up.

[oyvindberg]

I'm not entirely sure what to do about it btw. we could add a simple try/catch and just complain with a warning for these files, as I think it's a rather niche case (though curious to know what causes it on your side, maybe I'm not right about that).

The user flow here is that the sbt import generates a script which can replicate the generated (re-)sources the sbt build produced - but in a frozen state. You're meant to reimplement that script to generate the files properly into the destinations you can see in the script. That's why it's probably not an emergency if that stopgap script is not 100% complete.

If we want to do better we'll probably need to split the GeneratedFile structure into one for sources and one for resources. The reason why it's really beneficial to keep the generated sources in text form is that some string replacement of paths is done to them so that the snapshot tests bleep uses are portable between machines (see ).

The snap

[kpodsiad]

Cool, I already saw readme and because I'm familiar with BSP and scala-cli setup-ide part was easy ;) Unfortunately, something is off, I cloned fresh instance of repo and this is what I got as a result of bleep compile bleep-core@jvm213.

Details

➜  bleep2 git:(master) bleep compile bleep-core@jvm213
📙 Launching Bleep version 0.0.2 for ARM64 because you ran the AMD64 build. This is probably because you're running coursier compiled for AMD64. You can either try the coursier M1 runner at https://github.com/VirtusLab/coursier-m1 , or download and install bleep manually. Note that bleep will work this way, but startup will be slower.
📙 Refreshing /../bleep2/.bleep/builds/normal/.bloop...
📗 wrote bloop files [value => New: 39]
📗 bootstrapped in 223 ms
📗 Running source generator `bleep.scripts.GenerateResources` for project bleep-model@jvm213 because output didn't exist
📗 BSP / [script GenerateResources]: bootstrapped in 217 ms
📙 BSP / [script GenerateResources]: Writing /../bleep2/.bleep/generated-sources/bleep-model@jvm213/bleep.scripts.GenerateResources/bleep/model/BleepVersion.scala [target.project => bleep-model@jvm213]
📙 BSP / [script GenerateResources]: Writing /../bleep2/.bleep/generated-sources/bleep-model@jvm213/bleep.scripts.GenerateResources/bleep/model/Jvm.scala [target.project => bleep-model@jvm213]
📗 Run bleep.scripts.GenerateResources succeeded
📕 BSP: bleep-core@jvm213 object davidgregory084 is not a member of package io.github [value => file:///../bleep2/bleep-core/src/scala/bleep/GenBloopFiles.scala:8:7 until 8:32]

it's a rather niche case (though curious to know what causes it on your side, maybe I'm not right about that)

I'll try to examinate project and build on its own today or tomorrow.