"Private" Modules in Modules directory

[thomas]

Hello,

this might be a really special case which no one but me is interested in but I'll post it anyway since it seems rather easy to implement:

I have a few really special plug-ins or modified versions of existing plug-ins that wouldn't really be of any use for anything but my special cases. But I run these plug-ins on several sites and in my quest to keep everything up to date and n-sync I was wondering if it was possible to add "private" modules to the modules directory, which won't show up publicly but I can use processUpgrade to keep them up to date across my army of sites. Maybe this would help someone else, too.

Just a thought,

thomas

[DaveP]

...or maybe be able to configure processUpgrade to use a second GitHub source as well as the official repository?

[Pete]

Hi Thomas

I don't think that's practical really mainly because there is a workflow involved with modules appearing in the modules directory. Someone actually takes the time to approve entries (and updates) I think so opening it up to private use would add more burden to the person/people managing that.

If you use them across most of your sites, or you don't mind them sitting there uninstalled on the occasion you don't, why not create a Site Profile for yourself where these modules are bundled? It's pretty easy: http://modules.processwire.com/modules/process-export-profile/

So easy in fact I need to do this myself as I'm finding lots of repetition with my installations lately

[thomas]

Hi Pete,

thanks for the answer. I wasn't aware of the approval process and of course no one should need to approve my makeshift modules  

My problem isn't so much about the installation but more keeping everything up-to-date. I have 7 quite similar PW sites running and I always try to keep track of the changes and apply them to all the sites. I was thinkiung, maybe processUpgrade could help me with that.

@Dave, that might be an option too. That way I could build my own module directory

Thanks,

thomas

[LostKobrakai]

...or maybe be able to configure processUpgrade to use a second GitHub source as well as the official repository?

I think that may be the most useful option as the modules dir does already work with GitHub repos. So much of the parsing logic is already existing. To be able to access private ones there would be the need to authenticate to Github, but that should also be doable.

[teppo]

@Pete: actually, this doesn't sound that unfeasible to me. It might require new kind of structure for the directory though. Private modules wouldn't need to be approved at all, but on the other hand they should require authentication, and they would need to go through approval process if later changed to public.

Not sure if that's where we want to take the directory, of course, but I'm quite confident in PW's ability to handle this

Something along the lines of what @Dave mentioned has crossed my mind too. For an example, for our sites we don't allow installing modules from the directory, mainly because they still need to be internally audited. I'd be quite happy with the ability to set up a separate directory of my own, if that's what it takes, but perhaps there's an easier way to achieve the same result

[thomas]

Wouldn't you only need to set up a service that serves a JSON file with URLs and versions of your "private" modules? 

[apeisa]

I would love the idea to kill symlinks (our current method of keeping inhouse modules up to date) with this (private github repo + processupgrade).

[renobird]

+1 on this.

[Pete]

The idea of a separate URL and repo of modules that folks can set up themselves had crossed my mind, but that wasn't what I thought the OP was asking - now I read it again it was

I do like the idea of this if it's easy enough to do.

[thomas]

Well my next step after this was asked and rejected would have been to copy processUpgrade with my own module directory url and reverse engineer the JSON data it produces. So the purpose of my original question was actually to dodge some work