Problem/Motivation
ArchiveTar.php is unmaintained and unmaintainable because it is exempt from all coding standards, yet cannot be documented as external code.
Proposed resolution
With composer.json, we have the opportunity to cleanly bring in external components. Let's remove our unmaintained fork of Archive_Tar and move to Lootils Archiver.
Remaining tasks
Get an RTBC patch.
User interface changes
Nothing changes for the User Interface.
API changes
The API now uses Lootils\Archiver rather than Drupal\Compoenents\Archiver. It has a very similar interface, but allows us to keep external sources external and bring them in cleanly.
Related
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1673246.patch | 317.44 KB | robloach |
| #2 | 1673246.patch | 105.29 KB | robloach |
| lootils.patch | 101.37 KB | robloach |
Comments
Comment #1.0
(not verified) commentedUpdated issue summary.
Comment #2
robloachComment #2.0
robloachUpdated issue summary.
Comment #4
robloachHere's the correct patch... Hopefully.
Comment #4.0
robloachUpdated issue summary.
Comment #6
robloachComment #7
sunSo we are replacing one fork with another? What's the point of that?
I'm also very skeptical on pulling random stuff from the net into Drupal core. It makes sense to do that if there is a larger, active project and developer community behind some code. But if that is not the case, how well is the code maintained? How many non-merged forks are around? How long does the project exist, and does anyone else actually use it?
It looks like this component was created by someone of the Drupal community. That inherently leads to the question why we aren't making Drupal\Components its origin instead?
Comment #8
patcon commented@sun I'm not sure, but I think this a @RobLoach and @mfer's repo. I think the suggestion is just to manage it like an external lib as composer allows. But I don't have the full backstory, so it's just a guess :)
@RobLoach Not sure of the history behind Archiver, so can't comment directly, but if we were to use an external library, might it make sense to pull in one that is actually forked from the official?
https://github.com/pear/Archive_Tar
Seems a large part of the benefit of pulling in the repo with composer is that it can have it's own history that's easily traced to the canonical repo. This allows us to pull official changes into our fork in a more transparent way.
Maybe flag @chx and host it here so there's less confusion:
https://github.com/drupal
Or not sure where d.o stands in terms of hosting non-modules. Maybe that's better?
Comment #8.0
patcon commentedUpdated issue summary.
Comment #9
slashrsm commentedComment #10
slashrsm commentedLet's resurrect this from the ashes... :)
I think that it makes sense to pull in an external library even if it's author comes from the Drupal community. We already have such cases after all.
Lootils\Archiver seem to have more releases, while pear/Archive_Tar actually has some pulls (2 closed and 1 open). The latter is obviously a bit older, which means it has more history (and users I assume?). It seems like we forked pear/Archive_Tar since we wanted to replace default PHP with corresponding drupal_* functions. I'm not sure how to deal with this if we decide for Lootils\Archiver, as it seems it is the same situation there. One advantage of Lootils\Archiver seems to be support for various archive types (Tar & Zip), which could probably help us to kill even more code.
Having an unmaintained fork seems the worst option to me, though.
Comment #11
longwaveCan we rely on (or require) the PHP Phar extension when we want to deal with tar files? "It is possible to create and manipulate regular zip and tar files using the PharData class [...]": http://www.php.net/manual/en/class.phardata.php
Comment #12
robloachGreat idea, longwave. Would allow interacting with .phar files the same way you would a .zip file. Added an issue to Lootils\Archiver:
https://github.com/lootils/archiver/issues/3
Comment #13
droplet commentedComment #29
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #30
robloachThis goes back.