Prevent regeneration

[isaacabraham]

Is there an environment variable that we can use to conditionally stop regeneration (opposite of FORCE REGENERATE I suppose)? We're in a position where our build project references the "main" project that contains the Facil generated code etc., and under certain conditions we end up stuck where the build project can't run because the main project needs to build itself first, but that fails because Facil tries to connect to the DB to regenerate itself - but fails because the database doesn't exist, because the build process hasn't yet run...

[cmeeren]

Sounds like a simple thing to implement! But given your issue, it also kinda sounds like I would be implementing a foot-gun, or at least something that does not push you into the "pit of success". So I'd like to understand your issue a bit more first.

If I am understanding you correctly, the "Build" project sets up the database, and the "Main" project contains the Facil-generated stuff, and "Build" references "Main". This seems like a bad idea, as it gives the issue you describe. This is a cyclic dependency: Facil depends on the DB which depends on the code generated by Facil. Since you're an F# dev, I'm sure I don't have to tell you that cyclic dependencies are evil. Moreover, it's an unnecessary cyclic dependency: If it were actually necessary, it would of course be impossible to ever build the project.

I of course have very limited information to go on regarding your code, but given what little I can infer, I would strongly recommend you to refactor to remove the cyclic dependency. There seems to be no reason why the Facil-generated code that uses a DB should be a dependency of the code that sets up the DB. If you disagree, I am guessing Facil is generating code from multiple DBs, and can be split into multiple projects.

For the record, I always have a dedicated project for Facil-generated code (which I usually just call "DbGen"). This gives the following benefits:

• No weird dependencies; the only reason to reference the project is to use the Facil-generated code.
• Improved compilation times, since the Facil-generated code (which may be sizable) does not need to be re-compiled whenever something else changes.
• I can have a project file like this, which automatically picks up new SQL scripts, changes to SQL scripts and Facil config, etc.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <None Include="SQL\**\*.sql" />
    <None Include="facil.yaml" />
    <Compile Include="*.fs" />
  </ItemGroup>

  <ItemGroup>
    <UpToDateCheckInput Include="SQL\**\*.sql" />
    <UpToDateCheckInput Include="facil.yaml" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Facil" Version="2.5.7" />
    <PackageReference Update="FSharp.Core" Version="6.0.6" />
  </ItemGroup>

</Project>

Should probably officially document this somewhere...

In any case: I have probably spent longer just writing this than I would have spent implementing the flag you request, but I really want to make sure that it's not a bad idea, and right now I think it may be, since it may push developers out of the "pit of success".

[isaacabraham]

Hi @cmeeren and thanks for the detailed reply :-) And yes, we know that this is not an ideal place to be in. The reason for it is that the build project is also used not just for standard CI build but for some automation and ad-hoc operational business tasks that use types and functions from the "main" project. I'm hoping that we can move away from this approach in the short/medium term.

Splitting the Facil related code into its own project sounds like a really good idea and might work around the issue we're seeing here anyway, so we'll give that a try - thanks.

Would you mind leaving this issue open for discussion (or closing it and moving to a dedicated Discussion in the repo?).

[cmeeren]

Sure, I'll leave it open for the time being. 👍

[isaacabraham]

Can you ping me privately - Twitter or some DM solution (email?) - if you're interested, it might be good to jump on a quick call to talk about things.

[cmeeren]

I'm closing this issue since I think it is best solved by the tips I have provided, but feel free to continue discussion. I will re-open if I am convinced that something needs to be changed in Facil.