Closed sshashank124 closed 6 years ago
Hi, @sshashank124!
Thanks for opening this issue! I agree, this would be a nice-to-have feature. I have added a new optional permissions
option to the compile
action in version v0.6
of Astrality. It allows you to set the octal permission bits of the compiled template. For instance 0o777
or '777'
.
Read more about it here.
Example use:
module/scripts:
on_startup:
compile:
template: 'script.sh.template'
target: '/usr/local/bin/script.sh'
permissions: '555'
You should be able to use the new feature after having run pip install --upgrade astrality
.
Although this allows you to set the permission bits exactly, it does not allow you to just OR
the permission bit on top of the existing permission bits (whatever they might be), as in your example. I could add an additional executable
flag to the compile
action, which does exactly what you have written above, if you think that should be available. The drawback is yet another configuration option which might confuse people reading the documentation.
It should be said that changing the permissions of the compiled template can also be done by using a run
action:
module/scripts:
on_startup:
compile:
template: 'template/path'
run: 'chmod +x {template/path}'
Please let me know if this works for you, and don't hesitate with any future feature requests and/or bug reports ;)
By the way, I will implement copying over any relevant metadata from the template file to the compilation target as soon as I have the time. That hits me as reasonable default behaviour anyway, good suggestion!
Wow that was really fast! That is pretty much exactly what I wanted.
I agree with you that having more than one field to deal with permissions seems excessive however I think the functionality of just modifying a specific permission bit, without necessarily having to specify all the bits, is equally useful.
Would you consider expanding the functionality of the permissions
option itself to also allow the option to specify a string such as '+r'
, 'u+x'
, 'go-r'
, etc. as an alternative to specifying '700'
? I know that it brings it closer to just adding the run: chmod
option but I think that having a dedicated option for file permissions would be clearer.
Let me know what you think
Also, if you would like me to work on any feature, I would be happy to contribute anything I can. I had written a similar program (although nowhere near as featureful as this) for my needs before I knew about astrality
and I'm really looking forward to fully moving over to using this instead
It's cool that you have experience with a similar project, it's always nice to have someone to bounce ideas off on. I would really appreciate any contributions, software should be made together :tada:!
I have created a seperate issue for copying over the permissions of the template to the compile target here #3. I think that it might be a good start for contributing, especially since it was your idea in the first place :smiley:
I have also created an issue for contributing guidelines here #5. It contains some information for how to get started contributing. Any feedback on the issue regarding difficulties getting started is appreciated. Perhaps you can even solve the issue, but if the administrative parts bore you, you can skip it.
The next step could be implementing support for options of the chmod
-type: permissions: 'u+x'
. My thought regarding the implementation are written in this issue #4. If you want to do it that way is of course up to you.
If you are interested in any of these issues, I will assign them to you.
Do not hesitate to ask any questions!
PS:
For now, much of the magic happens in astrality.module
, especially in the two classes Module
and ModuleManager
. If you at some time want to understand the entire stack, I would begin there.
I am not too happy with how that part of the code ended up, as Module
and ModuleManager
are a bit too tightly coupled. I hope to split those classes up into smaller classes over time, to make it a bit more managable. One class for each action type is what I am considering.
That module is probably the greatest hurdle to overcome for new developers that want to grok the code.
Sounds great! I think that addresses this overarching issue then. We can take the individual discussions into their respective issues.
Are there any current or future plans to add support for setting certain metadata values of the result files generated from the templates. For example, in the case of bspwm's configuration file (bspwmrc) or certain shell scripts that I use, I would like to be able to make the generated files executable (and maybe eventually set specific file permissions). Since the templates are read, populated and then written out to a new file, metadata information such as file permissions (drwxrwxrwx) are lost.
Currently, I am using the following piece of code to achieve this:
os.chmod(filename, os.stat(filename).st_mode | stat.S_IEXEC)
It would be great if there was a way to either specify certain file permissions that one wishes to set for a file or to apply the same file permissions as the template file to the generated file