Forum OpenACS Development: Do we need to duplicate file listings of APM packages in info files and db?
It happens quite a lot that file listings in info files are out of sync with the file system. Either the programmer will forget to add/rermove files in the APM or he might forget to generate the XML file afterwards.
So when is synching an issue? Well in particular when installing/upgrading a package only sql files and message catalog files listed in the info file are sourced. Recently I added loads of message catalog files to a range of packages but those files were not added to the info files and thus do not get sourced on installation (adding them via the APM UI would have been quite tedious).
I think we should change the APM to always get files from the filesystem directly and use those files that match our clearly defined filepath patterns for different file types.
What do people think?
At minimum things should be consistent, either the .info file significance should be dumped or everything should be driven by it.
I'd label this a triage issue, i.e. there's a fair amount of code to whack away at, and it's not near the top of my list of things to whack away at in the near future.
On the other hand I really appreciate all the improvements to the APM you're making. If folks agree with the idea of driving things from the filesystem depending on the standard file patterns and you're sufficiently annoyed by the current state of affairs that you'll go ahead and rewrite it ... sure!
yes, consistency is another argument for the change that I am proposing.
As the saying goes, silence gives consent... As a first step I'll make the APM get message catalog files from the file system and try to do the same for sql files. If I find the time and inspiration I might attempt to remove the file listings in the info files altogether.
I'll post any progress in this thread.
At some point I would like to add mapping url stubs to different files which would need something like a manifest but I think until we do provide some useful functionality via a file manifest it's better not to have it at all.
I changed sourcing of sql files (install and upgrade) to use this proc instead of the info file. I also made catalog files be sourced directly from the filesystem and everything seems to be working ok.
I guess I should conclude this change then by removing all file tags in all info files, change the info file xml procs to not read/write files, remove all file db procs we don't need anymore, remove the apm_package_files table, and change the file manage page in the APM.
I feel pretty confident that all this stuff is superfluous now and can be removed. It's just that in terms of number of lines it's such a massive change that I'm a little reluctant to do it...