conflicting with camptocamp/archive

[igalic]

This module is conflicting with @camptocamp's archive
A sample issue from @voxpupuli's kafka: voxpupuli/puppet-kafka#61

I'd like to get this issue resolved my making the two modules' inputs compatible.

paging @mcanevet & @raphink, and @nanliu.

[madAndroid]

I've experienced this very frequently - would be great if this could be resolved somehow

[nanliu]

I wish it was as simple as mapping parameters, but I see several new parameters that need to be supported in archive and looks like some features are very specific to tar.

[raphink]

Should we try to merge the modules?

[jyaworski]

@raphink I would be open to merging them.

[nibalizer]

I would like to see them merge. How to do this?

[igalic]

There are two primary issues to make this module compatible with camptocamp/archive.

• camptocamp/archive doesn't have a class archive, and it probably cannot have such a thing

---

parameters

camptocamp/archive	voxpupuli/archive	name conflict	functionality conflict
ensure	ensure	✅	✅
name	name	✅	✅
src_target	filename	❌	❌
…	extract	✅	❌ camptocamp always extracts
target	extract_path	❌	✅
extension	…	✅	❌
…	extract_command	✅	❌
…	extract_flags	✅	❌
…	creates	✅	❌ hidden, not overridable in camptocamp
…	cleanup	✅	❌ no such thing in camptocamp
url	source	❌	✅
checksum	checksum_verify	❌	❌
digest_url	checksum_url	❌	✅
digest_type	checksum_type	❌	✅
digest_string	checksum	❌	❌
…	cookie	✅	❌
…	username	✅	❌
…	password	✅	❌
proxy_server	proxy_server	✅	✅
…	proxy_type	✅	❌
user	user	✅	✅
…	group	✅	❌

[terrimonster]

@igalic I can't thank you enough for pushing this forward, and organizing that table.

[igalic]

first attempt, could be better, but it's a first ugly attempt #176

[igalic]

next up we'll need wrappers for archive::download (and archive::extract)
and tests.
but that doesn't quite solve the problem of camptocamp/archive not being able to provide a class archive :D

[bbriggs]

Is the idea to have full feature pairity across both or to assist people moving from camptocamp/archive into this one? If it's the latter, we should be okay with having a superset of camptocamp/archive's features.

[raphink]

Whichever way works best. If it's easier to add wrappers to camptocamp's module, I'll merge them. If you prefer to provide the API here so users of camptocamp's module can migrate, that's good too.

[bbriggs]

I think for now we should aim to have vp/archive be a superset of camptocamp/archive and backport any necessary features.

[joshuaspence]

+1

[igalic]

i think with #174 and #176 merged, we can close this one as _good enough_