Enable to deploy websites in subdirectories. #5

GNUtoo commented 2023年12月07日 02:26:49 +01:00

Hi,

Here's a new patch to enable to deploy websites in subdirectories.

I also added a new website to test that, and it's based on the bunnies one.

Because of that the patch looks big but the following command can make it much smaller and easier to review:

git format-patch -M --find-copies-harder -1

Also, the commit shows as unverified and Codeberg shows this warning when we click on the red open lock:

WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS.

This is most likely because the commit is signed with a subkey and that the forge software used by codeberg doesn't support that.

Denis.

Hi, Here's a new patch to enable to deploy websites in subdirectories. I also added a new website to test that, and it's based on the bunnies one. Because of that the patch looks big but the following command can make it much smaller and easier to review: ```git format-patch -M --find-copies-harder -1``` Also, the commit shows as unverified and Codeberg shows this warning when we click on the red open lock: ```WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS.``` This is most likely because the commit is signed with a subkey and that the forge software used by codeberg doesn't support that. Denis.

vimuser commented 2023年12月07日 02:45:20 +01:00

the patch as it stands is a good start, but it will need substantial changes prior to merging. my response, copied from IRC, is thus:

01:31 <leah> GNUtoo: anyway, some first impressions of the patch:
01:31 <leah> i'm against including any lighttpd config examples in it
01:32 <leah> i'm not against the examples themselves, and i'm not against lighttpd
01:32 <leah> however, untitled should not specifically favour one httpd over another, at least not in code
01:32 <leah> httpd config should be provided for in the documentation
01:32 <leah> for example
01:32 <leah> docs/nginx/
01:32 <leah> docs/lighttpd/
01:32 <leah> docs/h2o/
01:33 <leah> docs/notapache/ <-- apache sucks
01:33 <leah> i mean on untitled documentation
01:33 <leah> GNUtoo: and your lighttpd template config could be shown there
01:33 <leah> for the user to copy/adapt, with instructions
01:33 <leah> but then
01:33 <leah> whether we do this in code, as in your current patch, or in documentation, i must ask:
01:34 <leah> this feels like "feature creep"
01:34 <leah> it feels out of scope for untitled
01:34 <leah> because the same configuration would be applicable to many other use-cases
01:34 <leah> GNUtoo: fortunately, i have a remedy for that
01:34 <leah> GNUtoo: check https://fedfree.org/
01:34 <leah> it's an untitled site. built with untitled. it's in git
01:34 <leah> see: https://codeberg.org/fedfree/
01:35 <leah> what i recommend is actually more ambitious:
01:35 <leah> if you want lighttpd, write a lighttpd guide for fedfree, like my nginx guide
01:35 <leah> then
01:35 <leah> untitled documentation can refer to it, with specific notes advising about how to use it with lighttpd
01:35 <leah> the same can be done with nginx
01:35 <leah> (nginx is covered, on fedfree.org)
01:36 <leah> GNUtoo: on that note, then, I don't like the current Makefile included in your patch;
01:36 <leah> actually, i question the need for a makefile in untitled, which basically uses the lbmk design principle
01:37 <leah> the functions you iumplement there seem to be very specific to a very specific use-case scenario
01:37 <leah> whereas untitled's design is supposed to be very flexible. you could host hundreds of websites with it. the current Makefile that you've added, does:
01:38 <leah> * hardcoded logic for deploying specific sites, specifically in ngilx (on make-check)
01:38 <leah> deploy: you are testing the build, by deploying the examples
01:38 <leah> in your logic, there is no check to see whether existing sites are there
01:38 <leah> for example, you do:
01:38 <leah> cp -a www-example www
01:39 <leah> and in general, that makefile is very lighttpd-centric
01:39 <leah> even if we were to only favour lighttpd, there are many ways to configure it, depending on host environment
01:39 <leah> now i will move on to your change to include/news.sh:
01:40 <leah> this change seems ok
01:40 <leah> though
01:40 <leah> you are saying:
01:40 <leah> _protocol=blablabla
01:40 <leah> you're filtering out DOMAIN
01:40 <leah> the way you do it is correct
01:40 <leah> but i have to wonder, what if we do:
01:40 <leah> DOMAIN --> make it only the domain
01:40 <leah> and actually have PROTOCOL in site.cfg
01:40 <leah> PROTOCOL="https"
01:40 <leah> DOMAIN="libreboot.org"
01:40 <leah> instead of
01:41 <leah> DOMAIN="httsp://libreboot.org"
01:41 <leah> we can filter out https:// and so on, for existing configurations (backwards compatibility)
01:41 <leah> and where DOMAIN isn't specified, default to https as good practise would indicate
01:41 <leah> just a nitpick. the logic otherwise looks fine
01:42 <leah> i'll copy/paste these messages to the PR page in a while, for referenceb y others. to be clear, i'm currently reviewing the patch and livestreaming to you my thoughts
01:42 <leah> your changes to meta() seem ok too
01:42 <leah> well
01:42 <leah> you're making use of my mktitle function
01:42 <leah> and my logic is shit
01:42 <leah> it should probably be scrapped. but you're working around my inanity. a lot of untitled needs to be basically rewritten.
01:42 <leah> in like
01:42 <leah> not sh
01:42 <leah> re-write the string processing stuff in go or something
01:43 <leah> the way i process title strings in shell script is a bit whack
01:43 <leah> the way i do it is efficient
01:43 <leah> that's not a problem for the patch though
01:43 <leah> ok so yeah, that's my current response:
01:43 <leah> the patch is a good start, but:
01:43 <leah> the above criticisms need to be addressed. i'll leave the patch open but this will need to be adjusted.
01:44 <leah> also, maybe some of this should be split into smaller patches
01:44 <leah> the matroshka site for example

the patch as it stands is a good start, but it will need substantial changes prior to merging. my response, copied from IRC, is thus: ``` 01:31 <leah> GNUtoo: anyway, some first impressions of the patch: 01:31 <leah> i'm against including any lighttpd config examples in it 01:32 <leah> i'm not against the examples themselves, and i'm not against lighttpd 01:32 <leah> however, untitled should not specifically favour one httpd over another, at least not in code 01:32 <leah> httpd config should be provided for in the documentation 01:32 <leah> for example 01:32 <leah> docs/nginx/ 01:32 <leah> docs/lighttpd/ 01:32 <leah> docs/h2o/ 01:33 <leah> docs/notapache/ <-- apache sucks 01:33 <leah> i mean on untitled documentation 01:33 <leah> GNUtoo: and your lighttpd template config could be shown there 01:33 <leah> for the user to copy/adapt, with instructions 01:33 <leah> but then 01:33 <leah> whether we do this in code, as in your current patch, or in documentation, i must ask: 01:34 <leah> this feels like "feature creep" 01:34 <leah> it feels out of scope for untitled 01:34 <leah> because the same configuration would be applicable to many other use-cases 01:34 <leah> GNUtoo: fortunately, i have a remedy for that 01:34 <leah> GNUtoo: check https://fedfree.org/ 01:34 <leah> it's an untitled site. built with untitled. it's in git 01:34 <leah> see: https://codeberg.org/fedfree/ 01:35 <leah> what i recommend is actually more ambitious: 01:35 <leah> if you want lighttpd, write a lighttpd guide for fedfree, like my nginx guide 01:35 <leah> then 01:35 <leah> untitled documentation can refer to it, with specific notes advising about how to use it with lighttpd 01:35 <leah> the same can be done with nginx 01:35 <leah> (nginx is covered, on fedfree.org) 01:36 <leah> GNUtoo: on that note, then, I don't like the current Makefile included in your patch; 01:36 <leah> actually, i question the need for a makefile in untitled, which basically uses the lbmk design principle 01:37 <leah> the functions you iumplement there seem to be very specific to a very specific use-case scenario 01:37 <leah> whereas untitled's design is supposed to be very flexible. you could host hundreds of websites with it. the current Makefile that you've added, does: 01:38 <leah> * hardcoded logic for deploying specific sites, specifically in ngilx (on make-check) 01:38 <leah> deploy: you are testing the build, by deploying the examples 01:38 <leah> in your logic, there is no check to see whether existing sites are there 01:38 <leah> for example, you do: 01:38 <leah> cp -a www-example www 01:39 <leah> and in general, that makefile is very lighttpd-centric 01:39 <leah> even if we were to only favour lighttpd, there are many ways to configure it, depending on host environment 01:39 <leah> now i will move on to your change to include/news.sh: 01:40 <leah> this change seems ok 01:40 <leah> though 01:40 <leah> you are saying: 01:40 <leah> _protocol=blablabla 01:40 <leah> you're filtering out DOMAIN 01:40 <leah> the way you do it is correct 01:40 <leah> but i have to wonder, what if we do: 01:40 <leah> DOMAIN --> make it only the domain 01:40 <leah> and actually have PROTOCOL in site.cfg 01:40 <leah> PROTOCOL="https" 01:40 <leah> DOMAIN="libreboot.org" 01:40 <leah> instead of 01:41 <leah> DOMAIN="httsp://libreboot.org" 01:41 <leah> we can filter out https:// and so on, for existing configurations (backwards compatibility) 01:41 <leah> and where DOMAIN isn't specified, default to https as good practise would indicate 01:41 <leah> just a nitpick. the logic otherwise looks fine 01:42 <leah> i'll copy/paste these messages to the PR page in a while, for referenceb y others. to be clear, i'm currently reviewing the patch and livestreaming to you my thoughts 01:42 <leah> your changes to meta() seem ok too 01:42 <leah> well 01:42 <leah> you're making use of my mktitle function 01:42 <leah> and my logic is shit 01:42 <leah> it should probably be scrapped. but you're working around my inanity. a lot of untitled needs to be basically rewritten. 01:42 <leah> in like 01:42 <leah> not sh 01:42 <leah> re-write the string processing stuff in go or something 01:43 <leah> the way i process title strings in shell script is a bit whack 01:43 <leah> the way i do it is efficient 01:43 <leah> that's not a problem for the patch though 01:43 <leah> ok so yeah, that's my current response: 01:43 <leah> the patch is a good start, but: 01:43 <leah> the above criticisms need to be addressed. i'll leave the patch open but this will need to be adjusted. 01:44 <leah> also, maybe some of this should be split into smaller patches 01:44 <leah> the matroshka site for example ```

GNUtoo commented 2023年12月07日 03:44:44 +01:00

The Makefile is only there for automatic testing, not for deploying real websites, and so that's why I picked a specific web server.

This is also why I added a new website in the same commit. But as you said my commit is big and can also be split.

So if you want me to keep the Makefile, I could split it and start adding the testing before in another commit.

If not I can simply remove it and still have the matrioska website as an example as I don't think that if it's worth converting the Makefile to some deployment documentation as deploying a static website doesn't really need specific documentation.

Also note that I didn't really document the Makefile in the README because I'm not the project maintainer, so for instance I can't tell people to run 'make' or 'make check' before sending patches. That's up to you to choose.

Once I know what to do with the Makefile, I'll be able to split the commits and also address your other concerns along the way.

Denis.

The Makefile is only there for automatic testing, not for deploying real websites, and so that's why I picked a specific web server. This is also why I added a new website in the same commit. But as you said my commit is big and can also be split. So if you want me to keep the Makefile, I could split it and start adding the testing before in another commit. If not I can simply remove it and still have the matrioska website as an example as I don't think that if it's worth converting the Makefile to some deployment documentation as deploying a static website doesn't really need specific documentation. Also note that I didn't really document the Makefile in the README because I'm not the project maintainer, so for instance I can't tell people to run 'make' or 'make check' before sending patches. That's up to you to choose. Once I know what to do with the Makefile, I'll be able to split the commits and also address your other concerns along the way. Denis.

vimuser commented 2023年12月07日 04:23:45 +01:00

I'm personally against the inclusion of Makefiles in any way, at this time. The current design of untitled does everything without Makefiles.

Yes, I propose:

Make a new PR, without the Makefile, and without anything pertaining to lighttpd.

The matrioska site can be a follow-up commit, after the main commit, and the main commit will contain the changes you made to the shell scripts.

I will then review the new PR, and close this one, cross referencing them.

I'm personally against the inclusion of Makefiles in any way, at this time. The current design of untitled does everything without Makefiles. Yes, I propose: Make a new PR, without the Makefile, and without anything pertaining to lighttpd. The matrioska site can be a follow-up commit, after the main commit, and the main commit will contain the changes you made to the shell scripts. I will then review the new PR, and close this one, cross referencing them.

vimuser commented 2024年01月03日 00:30:11 +01:00

closing because it was sent as directed, in this pull request, which i will review instead: #6

closing because it was sent as directed, in this pull request, which i will review instead: https://codeberg.org/vimuser/untitled/pulls/6