You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
allow distro-relative paths in custompios_path #206
the <dist>/src/custompios_path generated by src/make_custom_pi_os holds the absolute path to the CustomPiOS sources (so all the scripts (and sourced scriptlets) can find the other scripts).
this means, that it is useless to track this file in git (assuming that not everybody clones the repo into /home/guysoft/sources/CustomPiOS :-P)
probably this file could hold a relative path (at least if make_custom_pi_os was called via a relative path, such as ./src/make_custom_pi_os)?
i'm a bit unsure about the interaction with the vagrant snippet.
this obviously assumes that it actually makes sense to use a relative path, because the mydistro directory and the CustomPiOS/src folder are guaranteed to have a fixed relative path (e.g. because both are tracked in the same git repository). this is my current mode of operation (but I'm sure others do it differently).
it probably makes sense to have src/update-custompios-paths generate absolute paths, but allow relative paths.
right now it fails with:
python3: can't open file '<<CUSTOMPIOS_SRCDIR>>/mydistro/src/workspace/mount/../../src/execution_order.py': [Errno 2] No such file or directory
sidenote: my current workaround to this problem is to exclude the mydist/src/custompios_path from my repository, and instead have a wrapper-script that first creates this file (with the absolute path) and then call mydistro's build_dist.
so the priority of this issue is pretty low for me.
I initially didn't add git files in to the template folder of a new distro. But since 2013 when it started git has become the only version control out there. Though there are a few that use mercurial (though I rarely see .hgignore). So perhaps it might make sense to add now a default .gitignore.
ATM the vagrant is falling out of support no one is actually using it. And I have no time to test it.
one potential drawback i see is, that if the path in custompios_path does not exist (regardless of absolute or relative), the CUSTOM_PI_OS_PATH will then hold the same value as DIR.
this might give confusing error messages.
using realpath instead of the cd ... && pwd magic would fix this, but i guess it is not very portable (e.g. wouldn't run on macOS)
Activity
guysoft commentedon Oct 2, 2023
The relative path becomes a problem if you are using docker build environment. Or multiple CustomPiOS source trees.
I am not sure how to solve this without placing custompios in the execution PATH variable. So this was the compromise at the time.
What exactly are you proposing with relative paths? Relative to the working directory or the distro you are building?
umlaeute commentedon Oct 2, 2023
i think that relative paths to the distro is what I mean.
e.g.
$ . ├── LICENSE ├── README.md ├── mydistro │ └── src │ ├── build_dist │ ├── config │ └── custompios_path └── src ├── build ├── build_custom_os ├── build_docker ├── common.sh ├── config ├── config_sanity ├── custompios ├── make_custom_pi_os └── update-custompios-paths $ cat mydistro/src/custompios_path ../../srcthis obviously assumes that it actually makes sense to use a relative path, because the
mydistrodirectory and theCustomPiOS/srcfolder are guaranteed to have a fixed relative path (e.g. because both are tracked in the same git repository). this is my current mode of operation (but I'm sure others do it differently).it probably makes sense to have
src/update-custompios-pathsgenerate absolute paths, but allow relative paths.right now it fails with:
umlaeute commentedon Oct 2, 2023
sidenote: my current workaround to this problem is to exclude the
mydist/src/custompios_pathfrom my repository, and instead have a wrapper-script that first creates this file (with the absolute path) and then call mydistro'sbuild_dist.so the priority of this issue is pretty low for me.
[-]use relative paths in custompios_path[/-][+]allow distro-relative paths in custompios_path[/+]umlaeute commentedon Oct 2, 2023
i guess this might work:
afaict, the
custompios_pathfile is only read once (in the distro'sbuild_distscript) so it could be expanded to an absolute path right there.this still doesn't handle the expansion in
Vagrantfilethough (I'm afraid my ruby-knowledge is nil)umlaeute commentedon Oct 2, 2023
i guess that's the change required for the Vagrantfile:
note that i haven't actually tested this with Vagrant (just with a small, standalone ruby script)
guysoft commentedon Oct 2, 2023
Its part of .gitignore on my distros:
eg:
https://github.com/guysoft/OctoPi/blob/devel/.gitignore#L2
I initially didn't add git files in to the template folder of a new distro. But since 2013 when it started git has become the only version control out there. Though there are a few that use mercurial (though I rarely see .hgignore). So perhaps it might make sense to add now a default .gitignore.
ATM the vagrant is falling out of support no one is actually using it. And I have no time to test it.
umlaeute commentedon Oct 2, 2023
I initially didn't add git files in to the template folder of a new distro.
oops: with b10ed77 i have introduced a default
.gitignorefile (and continued to work on that with 25bff8b).so probably, you could just keep it and add more files?
and what do you think of #206 (comment)?
one potential drawback i see is, that if the path in
custompios_pathdoes not exist (regardless of absolute or relative), theCUSTOM_PI_OS_PATHwill then hold the same value asDIR.this might give confusing error messages.
using
realpathinstead of thecd ... && pwdmagic would fix this, but i guess it is not very portable (e.g. wouldn't run on macOS)