| 24 Nov 2020 |
 jozinek#0918 | now this is strange:
fury module update -c scala/compiler
The module reference scala/compiler could not be resolved.
| 20:37:30 |
 propensive | The blank layer is even blanker than that... | 20:37:46 |
| propensive | I just wanted to test that you could clone something. | 20:38:06 |
| propensive | I'd you'd like to see the setup for a compiler, there's a test here: https://github.com/propensive/fury/blob/main/test/passing/scala-2.13/script | 20:39:12 |
| propensive | That defines the compiler in a blank layer, like yours. | 20:39:36 |
| propensive | But I'd like to have a default import for users to get started, so they don't have to go through this process. | 20:39:49 |
| jozinek#0918 | sure, that makes sense | 20:40:11 |
| propensive | You can also try importing Scala 3 using fury layer import -l scala/scala3 | 20:40:12 |
| propensive | And then it should be available as a compiler. | 20:40:25 |
| propensive | So my intention is that you'd run fury layer init and unless you added a --bare flag, you would already have an ecosystem available to use. | 20:41:07 |
| propensive | I just had an interesting idea for how to make shading work... while I wasn't really thinking about it. 😉 | 23:17:25 |
| propensive | It seems like the best place to specify shading of a particular package would be at the layer import level. If you import a conflicting version of a particular project, you would potentially need to "rewire" an entire imported universe (i.e. from a layer) when you import that layer. | 23:22:57 |
| 25 Nov 2020 |
| jozinek#0918 | just to confirm, when using commands like:
fury module update -c scala/compiler
| 23:29:59 |
| jozinek#0918 | * just to confirm, when using commands like:
fury module update -c scala/compiler
the scala is refering to project scala and compiler to module compiler? | 23:30:24 |
| 26 Nov 2020 |
| propensive | Yes, that's right. | 00:01:24 |
| propensive | A compiler is "just a module" that's part of the build, though it must be a compiler module. | 00:02:06 |
| jozinek#0918 | I see, why is then fury project -p scala update -n sample not rename scala -> sample? | 00:03:21 |
| propensive | The command is wrong... | 00:03:45 |
| propensive | The arguments have to come after the commands, so it should be fury project update -p scala -n sample. | 00:04:15 |
| jozinek#0918 | right, I was puzzled that it did not return any warning/error | 00:05:45 |
| propensive | Did it give you a list of projects? | 00:06:16 |
| propensive | An error would be useful there. | 00:06:39 |
| jozinek#0918 | % fury project -p scala update -n sample
//T8JcHFU2
┌──┬─────────┬─────────┬─────────────┬─────────┬──────────┐
│ │ Project │ Modules │ Description │ License │ Compiler │
├──┼─────────┼─────────┼─────────────┼─────────┼──────────┤
│ │ scala │ 1 │ │ unknown │ - │
└──┴─────────┴─────────┴─────────────┴─────────┴──────────┘
| 00:07:06 |
| propensive | fury project is shorthand for fury project list. | 00:07:26 |
| propensive | And the -p might (I can't remember) filter on a single project. | 00:07:39 |
| propensive | A command line gets parsed into a sequence of commands, then each argument "captures" all the words between it and the next argument, and they get put in a map from String to Seq[String]. Most of the commands (like -n) which take a parameter value just use headOption to get it from the sequence. It's an error if it's None but not if the list is too long, which it would have been in this case. | 00:09:23 |
| jozinek#0918 | ok, thanks for explanatin | 00:10:16 |
| jozinek#0918 | * ok, thanks for explanation | 00:10:19 |
| propensive | No problem! How are you getting on with it? | 00:10:40 |
| propensive | If you're not using tab-completion, then I can imagine it would be very difficult to discover things... | 00:11:36 |
