Thanks for engaging in the discussion. Thoughts below...
On Saturday, December 19, 2015 at 9:07:49 AM UTC+13, [email protected] wrote: > > Hi hauptmech, thanks for your feedback! See below... > > On Sun, Nov 29, 2015 at 7:55 PM, hauptmech <[email protected] > <javascript:>> wrote: > >> >> The naming of files used by tup are inconsistent and difficult to >> remember. Having to look at the manual everytime I've been away from tup >> for a while will be annoying. Here's what I would change: >> >> ini files.... >> 1) just call it tup.ini everywhere. Easy to remember and correct syntaxt >> highlighting on all systems. >> > > What exactly do you mean by "it"? Just the current Tupfile.ini? Or also > the options files (.tup/options and such)? From your comment later about > variants it sounds like you might also mean tup.config, but I'm not sure of > the scope here. > .tup/options ~/.tupoptions /etc/tup/options Tupfile.ini The reason to name them the same is to give the (new) user confidence that it is the same config file format and affect for all of them. The reason to use the .ini extension is to hint the format (especially for unix people inclined to use # for comments in key=value files). tup.ini tells me that this is an ini (config) file for tup. > >> 2) ~/.config/tup/ might be a better location than ~/. >> > > Ahh, I wasn't aware of that. That looks reasonable to me. > > >> >> root directory... >> The vestigil Tupfile.ini feels a bit silly. I'd rather something >> different. Maybe a .tuproot so I don't have to look at it. Maybe a .tup >> directory with only an empty tup.ini. Maybe this is an unecessary feature. >> Maybe as you scan upward towards "/." the highest directory with a Tupfile >> is your root for the first build. >> > > There is some ongoing discussion about this in > https://github.com/gittup/tup/issues/132 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgittup%2Ftup%2Fissues%2F132&sa=D&sntz=1&usg=AFQjCNEA79T9YoFsoTlrajqQj1P9oIuL6w>. > > Maybe we should open a new issue for this and get some ideas together. > > Looking for the highest-level .tup directory sounds somewhat reasonable, > but we'd have to be careful since we don't want users to commit their > .tup/db file into source control. Maybe we could change the auto-generated > .gitignore file to ignore .tup/db (and other files) instead of .tup, though. > I see that discussion has continued. I'll post there if I have any new thoughts after reading. > > >> >> Tupfile & Tuprules.tup... >> *.tup works great. Tools (and developers) don't need to look inside to >> figure out what it's for. >> Tupfile -> build.tup, default.tup, tup.tup, fuk.tup ... anything.tup >> (Build.tup) >> > > "Tupfile" isn't so different from "Makefile" - IMO it's pretty > straightforward to look for both Tupfile and *.tup when applying tup > syntax. Eg in vim: > > au BufNewFile,BufRead Tupfile,*.tup setf tup > My main rationale is to give the new user confidence in the file format. Am I allowed the same syntax in Tupfile and Tuprules.tup? (I had this question when I was first learning about tup). > >> Variants... >> Again, tup.ini everywhere you use a tup config file. >> > > The tup.config file isn't an ini file though, it's supposed to be > compatible with the kernel's .config file generated by kconfig. > To be honest I missed the tup.config<>kernel .config relationship until I finally had time to look at tup-config today (which triggered me checking this post). One small issue is that there is little information on the kernel config file format. A section in the manual would be helpful. (CONFIG_key=value #comment) could be enough. > > >> include_rules... >> There's lots of times when you are digging around files and either don't >> know, or have forgotten, the syntax. It can help to explicitly list the >> file. >> >> include_rules Tuprules.tup >> >> It makes it easier start poking around to figure things out for those of >> us that prefer sticking forks in lightsockets than reading the manual. >> _rules might mislead someone to thing that the format is different... >> >> include_all Tuprules.tup >> > > That seems like a reasonable change. Though the Lua parser (and the future > Python parser) include the rules automatically, which means those filenames > are fixed (eg: Tuprules.lua). Is there a benefit to having projects specify > their own filename for Tuprules.tup? > I started thinking about this and discovered it's much more complex than I have time for today. Some random thoughts: The main motivation for me is to change the magic incantation to something discoverable. I much prefer filenames be established by convention rather than hard-coded. It seems that include_rules is trying to replace environment variables (and the way they propogate through a tree of processes). It makes me wonder if there is any situation where you would not want include_rules. > > >> If you think any of the tweaks above are worth implementing, I'm happy to >> issue a pull request. >> >> > Thanks! I think re-opening the Tupfile.ini / how-do-we-auto-init > discussion is worthwhile. It may be a good idea to revisit the filenames > that tup uses as well. If/when I add the python parser, tup will be looking > for Tupfile, Tupfile.lua, Tupfile.py, Tuprules.tup, Tuprules.lua, > Tuprules.py, tup.config, Tupdefault, Tupdefault.lua, Tupdefault.py, and > Tupfile.ini (I think that's all of them). Seems a bit excessive when you > write them out :) > > Changing filenames and such will likely be backward-incompatible changes. > However, it's likely that the v0.8.0 release will be backward incompatible > anyway, so that might be a good time to introduce these kinds of changes. > > -Mike > I'll open an issue or two for further discussion on the name changes. -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
