Sort out composer-installability

hhvm / xhp-lib

Class libraries for XHP. XHP is a Hack feature that augments the syntax of the language such that XML document fragments become valid Hack expressions.

http://facebook.github.io/xhp-lib/

MIT License

1.38k stars 160 forks source link

Sort out composer-installability #71

Closed fredemmott closed 9 years ago

fredemmott commented 10 years ago

cc @ptarjan @daniel15 @rdewilde @Swahvay

Thoughts:

https://packagist.org/packages/hhvm/xhp should die in favor of https://packagist.org/packages/facebook/xhp as XHP isn't HHVM-specific - and people shouldn't have to modify their composer.json to switch from PHP5 to HHVM
Facebook and/or the XHP maintainers should have admin access to https://packagist.org/packages/facebook/xhp
it should be backed by the facebook/xhp repository, not a fork. This means that we need to add a composer.json here, and that composer will be downloading the full tree, not just php-lib. Alternatively, the php-lib could be removed from this repository, and another repository becomes the canonical source for it.
if we end up with a separate canonical source for php-lib, it needs to retain history, including tags. The current forks appear to be a copy of the files, without full history. It should either be a fork with everything else removed, or a fork with git-filter-branch done to remove it.

Daniel15 commented 10 years ago

I think there's value in having two packages - One can use Hack while the other can use plain PHP. There's a hackified fork of the XHP code (I think it's this one from @Swahvay https://github.com/facebook/xhp/tree/hack). The way I see it, facebook/xhp should be plain PHP and work on both PHP and HHVM, whereas hhvm/xhp should be Hack and only work on HHVM (but maybe with more obvious names like facebook/xhp for PHP and facebook/xhp-hack for Hack). Having said that, both could live in the same repository.

cc @pvh as well since he's the maintainer of the hhvm/xhp package.

fredemmott commented 10 years ago

I don't think there's a need for two packages - can't you choose between following dev-master vs dev-hack, and tagging the versions separately?

Also, this depends on what the plan is for supporting both branches, regardless of composer.

RdeWilde commented 10 years ago

Alternatively, the php-lib could be removed from this repository, and another repository becomes the canonical source for it. if we end up with a separate canonical source for php-lib, it needs to retain history, including tags. The current forks appear to be a copy of the files, without full history. It should either be a fork with everything else removed, or a fork with git-filter-branch done to remove it.

This one I'd prefer.

fredemmott commented 9 years ago

I'm planning to:

move the PHP5 extension to facebookarchive/xhp-php5-extension (preserving history)
move the class library to facebook/xhp-lib (preserving history)
make this repository a stub, with README.md pointing to both (after a few months, I'll remove this repository entirely)
leave sorting out Hack vs PHP for now

The primary motivations are:

this helps with composer
the PHP5 extension is unmaintained, but the class library isn't. Moving it to facebookarchive makes it clearer

I'll probably do this on the 15th-19th or early next year. Feedback very welcome :)

fredemmott commented 9 years ago

cc @simonwelsh

simonwelsh commented 9 years ago

I don't really use the PHP version (I've got it installed on one server I haven't migrated to HHVM yet), so removing that doesn't worry me ;)

I was planning on PRing the removal of everything other than the phplib for the Hack branch, so that it can be used with composer or submodules without all of this redundant cruft. :+1: for doing that.

The main problem with maintaining the PHP5 and Hack classes is keeping them in sync. That's still a problem now though, so this won't change this. I suspect that once PHP7 is released, it won't make sense to maintain the PHP classes without updating the extension, so that may sort itself out in the next couple of years anyway.

You'll probably want to talk to @RdeWilde about taking over the facebook/xhp composer package, or use facebook/xhp-lib instead.

To help with having Hack and PHP versions of the same package, I currently tag my projects with different major versions (2.* for Hack, 1.* for PHP). Allows for people to use tagged versions for the right branch while still getting updates.

RdeWilde commented 9 years ago

If you need to take over any package, just let me now, fine with me.

fredemmott commented 9 years ago

Almost ready to go:

https://github.com/facebookarchive/xhp-php5-extension https://github.com/fredemmott/xhp-lib

Plan is:

test composer installability of xhp-lib
rename this repository to xhp-lib (so that the issues are preserved)
push fredemmott/xhp-lib's changes here

TJ09 commented 9 years ago

Still agree with the splitting of xhp-lib and xhp-php5-extension, though still not a huge fan of archiving the extension.

fredemmott commented 9 years ago

In practice, Facebook already doesn't support the PHP5 extension, and hasn't for some time. Archiving it is just making this clear, not really changing anything.

TJ09 commented 9 years ago

My observation has been that the facebookarchive account is essentially where already-dead projects go to become more dead; I couldn't find a single one that had any commits since being moved there, and the ones I looked at hadn't had any commits in over a year prior to being archived. On the other hand, I have contributed a number of fixes to the extension in the past few months, and have been working on adding support for PHP 5.6 syntax.

Obviously I can just fork the repo and go from there (yay open source), but the biggest issue at play is discoverability. I do think XHP has value outside of its use in HHVM.

fredemmott commented 9 years ago

Long-term, XHP is dead outside of HHVM unless there's sufficient interest and commitment to both maintain the PHP5 extension, and to create a PHP7 extension; this commitment isn't going to come from Facebook, and we want to make this clear.

We'll be happy to link to a canonical fork if there's a consensus.

fredemmott commented 9 years ago

Done, and composer.json added. Composer package is 'facebook/xhp-lib'.