On Friday, December 18, 2015 at 3:07:49 PM UTC-5, [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. > > >> 2) ~/.config/tup/ might be a better location than ~/. >> > > Ahh, I wasn't aware of that. That looks reasonable to me. >
I agree that this seems like a better location. > > >> >> 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. 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. > > > >> >> 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 > > >> 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. > > >> 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 think I'm generally against this. It seems generally good to keep the number of tup specific file names to a minimum, and allowing tupfiles to specify potentially arbitrary files to include will likely make understanding a tup hierarchy (from both a human and machine perspective) unnecessarily more complicated. I understand the desire to have the tuprules file be more explicit as I often forget the command to include them as well, but I'm not convinced that this is the correct approach. > > >> 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 :) > The names of all tup related files certainly warrant some discussion in the wake of making backwards incompatible changes. In lieu of opening a full discussion now, I will say something more consistent like Tup{file,rules,default}.{tup,lua,py,ini,config} would be much more consistent. > 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 > -- -- 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.
