search

maxmind / MaxMind-DB-Reader-php

PHP Reader for the MaxMind DB Database Format
Apache License 2.0
642 stars 83 forks source link

Please include the examples and tests in the release tarball #55

Open orlitzky opened 7 years ago

orlitzky commented 7 years ago

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 commented 5 years ago

+1

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

oschwald commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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,

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.