Reorganize SCSS sources

[benjaoming]

It's hard to contribute to styling because the current layout of SCSS files doesn't reveal which files are original Bootstrap files (that should not be touched) and which are custom files (where changes should happen)

[oscarmcm]

Now, there's no real need to use a bunch of SCSS files, or are we going to continue supporting this?

https://getbootstrap.com/docs/4.6/getting-started/theming/

[benjaoming]

I would think that we still need to have the source Bootstrap files that we are building with? But we can split our own custom overrides from those so that everything from Bootstrap is kept separately and can easily be updated.

[benjaoming]

I think the layout that they suggest looks good:

your-project/
├── scss
│   └── custom.scss
└── bootstrap/
    ├── js
    └── scss

[oscarmcm]

I would think that we still need to have the source Bootstrap files

Yes, we still need the imports like this:

// Custom.scss
// Option A: Include all of Bootstrap

// Include any default variable overrides here (though functions won't be available)

@import "../node_modules/bootstrap/scss/bootstrap";

// Then add additional custom code here

But I think that this will no longer be required to have all of this unless you still want to continue using the current structure.

[benjaoming]

I don't think we should have any Node stack in the project for this reason. That'd have to happen because of something more important.

I have so far benefited from having the Bootstrap source files in the repo because I often read the code.

[benjaoming]

But I think that this will no longer be required to have all of this unless you still want to continue using the current structure.

I want to continue having the Bootstrap source files but separate them from the files that contain overrides/additions.

I'd want to avoid any Node installation of Bootstrap for as long as possible, but certainly consider it if there were other things from Node 👍

[benjaoming]

I want to also remove the CSS artifacts from the repo. I find that hatch has so-called "hooks" to ensure that something happens during the build process. We can use those hooks to build the SCSS.

I know that we currently have the assets command that we can run, but I'd like somehow that the build and release process doesn't come with a risk of un-synced assets by baking the assets building into the wheel/sdist building.

1. By writing our own hatch hook: https://hatch.pypa.io/1.9/plugins/build-hook/reference/
2. By using a plugin for hatch: https://github.com/rmorshea/hatch-build-scripts

Do you have any experience with this @oscarmcm ? ❤️

[oscarmcm]

Hey, sure I can take care it, and I think it's a good idea to move that outside of the scrips section. I'll be attending PyTexas this week so I'll try to get some time to work on it first.

[benjaoming]

That sounds fantastic! Thanks ❤️ I'll reorganize the SCSS either before or after this change, but I think we can keep them separate since it's just a matter of updating the sassc command with the new paths.

[oscarmcm]

does the reorganize stuff means to use the new BS5 layout? or just to be more streamlined with the hooks change?

[benjaoming]

I want to begin by relocating the CSS and SCSS files in a separate change, but then I feel like the road is paved to start the BS5 upgrade 👍

[oscarmcm]

@benjaoming maybe we don't need a new hook for this, maybe its just add a new dependency and ofc the proper configurations.

https://github.com/rmorshea/hatch-build-scripts

wdyt?

[benjaoming]

@oscarmcm that's indeed the dependency that I mentioned in the question ;) I'm not good at assessing whether to have a plugin instead of writing 1 hook... dependencies have a price in maintenance, risk of abandonment and supply chain security.. but then on the other hand, developing and maintaining a hook probably has disadvantages too :)

[oscarmcm]

oh sorry about not catching it right, gonna check what's the most easy solution for this without going crazy.

[benjaoming]

yes, agreed, it seems like it's immediately going to be easy to spend a disproportional amount of time on a solution for a little problem... it was very "intuitive" with a Makefile, yet here there seems to be an immediate uphill struggle.

[oscarmcm]

@benjaoming I was thinking on moving the Bootstrap files to a git submodule, that way we can lock the BS version inside the Git history without having all the files tracked.

I'll probably add some hatch scripts to sync the submodule as well.

[benjaoming]

@oscarmcm from experience, I would say that submodules are not nice. I understand that vendoring all their source files looks ugly, but in reality, they aren't updated so often and don't seem to cause issues.

I don't mean to say that having some NPM infrastructure to deal with Bootstrap releases is nicer. But checking out Bootstrap's repo also comes with a cost.

But do you think it's worth the effort?

We could also add a script to hatch that downloads and unzips a specific version of bootstrap releases? :)