Please include the examples and tests in the release tarball

[orlitzky]

Hi, I'm creating a Gentoo package for MaxMind-DB-Reader-php, and the examples and tests would be useful for us. The examples get installed globally, and we have the option to run the tests before installation to make sure that everything works as expected (before, say, proceeding with an upgrade).

[remicollet]

+1

Everything is part of the project, using .gitattributes is a terrible hack.

[oschwald]

I don't have a strong opinion on this. This was added in #39 at the request of composer users, who indeed do not need these files normally. I'd argue that dev-bin doesn't belong in the release tarballs, but the tests and example would make sense.

@mlocati, thoughts?

[mlocati]

Excluding unused files for normal users is much safer (otherwise we have check that eery included file doesn't have any flaw/security issues).

If you want to install the full package using composer, just run

composer install --prefer-source

If you are not using composer, but you still want the full package, just run

git clone --depth=1 https://github.com/maxmind/MaxMind-DB-Reader-php.git maxmind
rm -rf maxmind/.git

[orlitzky]

If you are not using composer, but you still want the full package, just run

git clone --depth=1 https://github.com/maxmind/MaxMind-DB-Reader-php.git maxmind
rm -rf maxmind/.git

This doesn't help with the original problem: I'm creating a package for Gentoo...

[remicollet]

@mlocati just a reminder, composer is NOT an installer (but a Dependency Manager for PHP )

PHP don't have any (well, the old pear/pecl command still work)

BTW, this have already been discussed ad nauseam... .gitattributes is an ack to workaround the lack of installer for PHP. You always have some work to "install" an appllication, composer install on the dev, generate the asset, minify, cleanup dev tools... etc... then deploy to prod.

@oschwald do what is simpler for you, we are now used to create git snapshot for downstream distribution (and we are the butt of all-non-php-developers jokes)

[mlocati]

If you are not using composer, but you still want the full package, just run
git clone --depth=1 https://github.com/maxmind/MaxMind-DB-Reader-php.git maxmind
rm -rf maxmind/.git

This doesn't help with the original problem: I'm creating a package for Gentoo...

I don't know the Gentoo package creation process: what's needed for it?

[mlocati]

@mlocati just a reminder, composer is NOT an installer (but a Dependency Manager for PHP )

@remicollet composer is not a system-wide installer, but a project dependency manager. That means that it can install dependencies on a project basis. So, it still installs packages.

You always have some work to "install" an appllication, composer install on the dev, generate the asset, minify, cleanup dev tools... etc... then deploy to prod.

Not always: for instance, this package doesn't have any asset to be generated, nothing to be minified. And for cleaning up dev tools we have .gitattributes (I know, it has its downsides, but it's the only viable approach we have).

[orlitzky]

I don't know the Gentoo package creation process: what's needed for it?

Basically just a tarball. We're a source-based distribution, so a "package" is essentially a series of steps that will be executed on the user's machine to get the thing installed. Something like the following,

• Download the tarball (from our mirrors, or maybe directly from github).
• Check the hash against my (or whoever packaged it) signature.
• Extract it, and do all the things that @remicollet alluded to: build it, run the tests, remove any extra junk...
• Install everything to where it goes: source code usually in PHP's global include_dir, documentation somewhere else.

The git clone on the fly doesn't work for a few reasons:

1. There's no tarball for me to verify and sign.
2. We can't access the network on-the-fly during the build process; many users install packages off-line.
3. Our mirror infrastructure only mirrors files, and doesn't serve up git repos.
4. Cloning a git repo is a lot slower and uses more space than downloading a release tarball.
5. The contents of the package need to be fixed, and a git clone is going to change.
6. Doing a git clone requires git, which pulls in a million other dependencies that aren't actually needed to install this library.

And probably some others, yada yada. But basically we're all (distro packagers) trying to do the same thing. Take a fixed version from upstream and figure out a way to install it once, globally.

The existing release tarball already works, but we can't run the tests or install the examples, because they're not in there.

[mlocati]

What about a TravisCI job (which can also be scheduled to be executed daily with a TravisCI cron job), scheduled daily, that updates the GitHub releases by adding a full-repository.tgz file if it's missing?
So, for example, you could access the 1.4.0 repository by fetching https://github.com/maxmind/MaxMind-DB-Reader-php/releases/download/v1.4.0/full-repository.tgz

[orlitzky]

It sounds like that would work, though if you're feeling extra nice you could name them something like MaxMind-DB-Reader-php-1.4.0-full.tar.gz so that we can tell the tarballs apart without renaming them (which is not a big deal, either).

[oschwald]

Would uploading a "release" tarball to GitHub with everything but dev-bin and the dot files (e.g., the Travis config) work for everyone? If so, we can add that to our release script.

[orlitzky]

Would uploading a "release" tarball to GitHub with everything but dev-bin and the dot files (e.g., the Travis config) work for everyone? If so, we can add that to our release script.

That sounds perfect.