MOD Installation

[Oleg]

I think people who are afraid of patch files simply have not seen them in proper presentation.

A patch with colored additions/removals, configurable amount of context, line numbers and ability to view new and old version of the file is very readable.

If you, the person reading this, consider patch files unreadable I suggest reading some diffs in trac.

[igorw]

MODx is proprietary (and ugly) format, that is meant to be used by humans, and is not friendly. it is ridiculously difficult to create, and not at all friendly to apply.

While I agree that MODX is ugly, there are several tools that are evolving. MODX generator allows easy creation of instructions, MODX creator/editor are great apps to add meta data. By making the automod functionality cli-friendly applying MODs can become almost as easy as applying a patch.

[imkingdavid]

I'd prefer to see these kind of actions in a separate file instead of mixing file changes and db changes.

I don't mind having it in separate files for clarity and such, I just think that having to first apply all the code changes with one program and then apply the sql with another is too much. Personally it isn't too big of a deal, but I think that the majority of admins would appreciate a more single-step approach. So if it is split into multiple files I think that the other file should still be run by AutoMOD to decrease the amount of steps required.

As for patch vs. MODx, I have very little (if any) experience with patches. I use a repository for version control for my personal projects, but I have never had to apply or use a patch. So forgive me if I'm a little biased in favor of MODx instead of having to learn yet another way of doing things.

[Oleg]

You realize of course that patches are universally useful while modx is phpbb (version) specific, right?

Even if patch can't express inline finds, at the moment of installation automod locates the lines it's going to modify and alter them. If in fact modx inline finds cannot be translated to patch hunks using modx information only, then patch generation is actually domain of automod as opposed to modx tools contrary to what was stated earlier.

With modx vs patch, the point is that either modx tools or automod are very close to generating patches because they either do the edits or look at the edits. I think adding patch output has to be relatively easy compared to everything else automod does.

The value in working with patches is in lowering the barrier of entry to mods. There are many requests for mods on the main board, and there are many developers capable of writing said mods. One of the issues with developing a mod is writing modx which is a manual process and could well take more time than actually coding the mod. So more efficient developers for whom this is even more true shy away from writing mods for other people. I know one developer for whom this is true.

[imkingdavid]

I do agree with the time consuming nature of MODx, although there are tools to help speed up the process. One of the things I dislike most about releasing new versions is having to not only provide updated installation instructions but also provide update instructions. Using a diff could make this process even faster.
I guess a "generate diff" feature inside AutoMOD would be helpful and should be considered, even if AutoMOD does not end up supporting the use of patches to apply the MOD with AutoMOD.

[DavidIQ]

You realize of course that patches are universally useful while modx is phpbb (version) specific, right?

We're talking about phpBB here so I don't see how patches being universal has any relevance. MODX has been around for over 2 years now so it could be argued that for phpBB, MODX is universal now since all MODs use it. If the point here is that it would be nice to generate a diff file instead of MODX or in conjunction with MODX and have the MOD installer handle that then that might be something to look into.

[A_Jelly_Doughnut]

IMO the code base of AutoMOD needs to be cleaned up. There needs to be better separation of concerns, less dependencies between the components. The MODX parser should use SimpleXML and XPath. There should be an API that can be used to install MODs programatically without having to load the whole phpBB environment with $template, trigger_error, etc.

Yes, yes, and yes.

Since this is a new addition to phpBB, there's a lot you can do with it. You can use dependency injection (passing information into classes instead of depending on globals).

Dependency injection is an interesting idea, especially for things like the $db and $user objects...

You can use Exceptions instead of trigger_error, which means you don't have to worry that trigger_error will mess up your CLI output.

Another reasonable idea.

The file writing API is frankly a bit of a mess. Since there is a proper storage abstraction planned for 3.1, it may be possible to use that too for FTP, SFTP, etc.

Before I could fully comment, I'd need more information on what exactly will be implemented as this "storage abstraction."

There has already been some work on a CLI for 3.1

First I've heard about this. Someone care to elaborate?

====================

I would like a facility to convert modx files to patch files and sql files.

I'm not seeing the broad applicability of a feature like this.

====================

recently we switched to git. it is very reasonable to assume that every MOD developer has a full repo of the code.

Git is irrelevant, because it provides nothing (with regards to creating diffs) that could not be done with SVN or even CVS.

====================

A patch with colored additions/removals, configurable amount of context, line numbers and ability to view new and old version of the file is very readable.

If you, the person reading this, consider patch files unreadable I suggest reading some diffs in trac.

This has been the default view for patches in web interfaces for years, and while its nicer than the pure .diff file, it is still not intended for human application. This is a stated goal of phpBB for the forseeable future. Furthermore, I don't think anyone has the will to force another completely new format on MOD authors. (And for what its worth, I would argue not all MOD authors, probably not even a majority, are familiar with patches, so it would be new to them)

===================

I just think that having to first apply all the code changes with one program and then apply the sql with another is too much. Personally it isn't too big of a deal, but I think that the majority of admins would appreciate a more single-step approach. So if it is split into multiple files I think that the other file should still be run by AutoMOD to decrease the amount of steps required.

In principle, I agree.

=================

Even if patch can't express inline finds, at the moment of installation automod locates the lines it's going to modify and alter them. If in fact modx inline finds cannot be translated to patch hunks using modx information only, then patch generation is actually domain of automod as opposed to modx tools contrary to what was stated earlier.

I don't think I follow the logic. What does patch generation have to do with installing a MOD?

[igorw]

I don't mind having it in separate files for clarity and such, I just think that having to first apply all the code changes with one program and then apply the sql with another is too much.

Well, you can always create a wrapper program that runs both, so it's really a non-issue. And yes, I agree that installing a MOD in one step must be possible.

[igorw]

Before I could fully comment, I'd need more information on what exactly will be implemented as this "storage abstraction."

Henry mentioned it would be similar to cache. I guess would be something like a watered down filesystem. So you have ability to write resource, read resource, check if resource exists. Perhaps even list items and have namespacing (eg. directories). And also provide a public link in case of avatars, attachments.

First I've heard about this (phpBB 3.1 CLI). Someone care to elaborate?

It's something Cullen (formerly Brainy) started working on. I haven't seen any posts about it, I just came across the branch on github.

[naderman]

Before I could fully comment, I'd need more information on what exactly will be implemented as this "storage abstraction."

Henry mentioned it would be similar to cache. I guess would be something like a watered down filesystem. So you have ability to write resource, read resource, check if resource exists. Perhaps even list items and have namespacing (eg. directories). And also provide a public link in case of avatars, attachments.

That part was purely meant for user uploaded files. Not sure how this relates?