Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
base system
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
7 Apr 2014 at 12:35 UTC
Updated:
29 Jul 2014 at 23:32 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
catchComment #2
mile23It would be handy in /vendor, but...
https://github.com/pear/Archive_Tar/blob/master/Archive/Tar.php#L42
Ouch.
Comment #3
catchAlso we deliberately forked this when it first went in to use the drupal_* wrappers, pulling in the unforked PEAR library into vendor would be a functional regression.
Comment #4
catchComment #5
ParisLiakos commentedyes lets move it already. like catch said removing the drupal_* wrappers there is a functional regression. and well with those there, they cant be in component, because the dependencies of those wrappers go down all the way to our stream wrapper system.
We need to open a followup to fix coding standards in ArchiverTar.php though.
I just rerolled it now, and replaced Implements... with {@inheritdoc} since we are touching them already
Comment #7
webchickCommitted and pushed to 8.x, but this really feels like stretching the definition of a critical. :)
Comment #9
catch@Angie it's actually the last issue from #1929270: [meta] Drupal-agnostic components should not be calling Drupal functions and allowed me to downgrade #2043773: Replace php function wrappers in file.inc with a Drupal\Core\File\FileSystem class to major.
The Component directory is a 'feature' of re-usable libraries. If you can't re-use them, then it is completely pointless to have the two directories.