Closed baronfel closed 3 months ago
If this is approved, I'd be happy to contribute an MR for it.
Approved
The associated MR was merged, can a new release be done that includes the new packages?
I can help with publishing but I am not sure about dependencies ... They looks wrong
FsLexYacc.Runtime
?FsLex.Core
depends on metapackage FsLexYacc
?FsLexYacc
has no dependencies? Metadata:
id: FsLex.Core
Dependencies:
.NETStandard2.0:
FSharp.Core: '>= 4.6.2'
FsLexYacc: '>= 10.2.0'
Metadata:
id: FsYacc.Core
Dependencies:
.NETStandard2.0:
FSharp.Core: '>= 4.6.2'
Metadata:
id: FsLexYacc.Runtime
Dependencies:
.NETStandard2.0:
FSharp.Core: '>= 4.6.2'
Metadata:
id: FsLexYacc
Dependencies:
good eyes, the following packages should be published:
so it looks like there are some package authoring issues introduced with my last PR. I can investigate those.
FsLexYacc old combined package, no dependencies
why? do we have a goal to abandon this package one day?
Can we make FsLexYacc
empty package with dependency on FsLex.Core
and FsYacc.Core
?
It couldn't be empty just yet, because the .Core packages don't contain the actual executable binaries for fslex/fsyacc, only the parsing/generation/tooling code. The 'drivers' still live in their individual projects, and I didn't want to change the distribution mechanism for them (since they are most commonly distributed as the build-tooling package).
OK got it.
Right now FsLexYacc
had dependency on FsLexYacc.Runtime
. Why this dependency disappeared after refactoring?
Because it didn't actually have a dependency on FsLexYacc.Runtime, because it embedded that dll in the metapackage already. And since the meta-package didn't contain libraries for others to reference, it made no sense to me to also include a package reference to the FsLexYacc.Runtime nuget.
Because it didn't actually have a dependency on FsLexYacc.Runtime, because it embedded that dll in the metapackage already.
When you generate code (fs
) from fsl
/fsy
using (FsLex
/FsYacc
) you need FsLexYacc.Runtime.dll
do build it and to execute it.
FsLexYacc.Runtime
project has lib
folder with dll that become target project dependency.FsLexYacc
does not have lib
folder and contains only build-time tools.And since the meta-package didn't contain libraries for others to reference, it made no sense to me to also include a package reference to the FsLexYacc.Runtime nuget.
I believe with this approach user's will have to manually add two NuGet dependencies (one to compile fsl/fsy and one to compile generated code). So, it may sense to keep the dependency between packages to simplify Getting started
experience.
Ah, that explanation makes perfect sense. I'll try to send a PR that re-aligns the packages with our discussion here.
Thank you for taking the time to work through this with me!
Hey @baronfel , is there anything still missing here or can this be closed because of #144?
Good spot @dawedawe 👍
Description
Currently, the ASTs and parsers for FsLex and FsYacc are internal to the tools themselves. It would be wonderful to have a published version of the AST structures and parsers for them, to enable me to improve FSAutoComplete (the LSP engine behind Ionide in VSCode) as well as other editors with better tooling around these files.
Having access to these structures would allow:
I propose that a new layer of library be added between each of fsyacc and fslex like so:
such that most of the AST, parsers, and logic for each project are pushed down into the core layers, and the outer projects mainly orchestrate calling into this core logic.