Ankündigung

Einklappen
Keine Ankündigung bisher.

[Composer] Code zu speziellem Tag/Commit (git, svn, …) einbinden (optimal als "dist")

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Composer] Code zu speziellem Tag/Commit (git, svn, …) einbinden (optimal als "dist")

    Der Hintergrund ist dieser Thread bei Beitrag #25 und davor. (Danach steht in dem Thread nichts mehr zu dem Thema.)

    - http://www.php.de/php-einsteiger/111...oder-nein.html

    Ich zitiere mal der Einfachheit halber den Kontext. Dann muss eigentlich niemand den anderen Thread anklicken.
    Zitat von rkr
    Seit wann kann man Package-Versionen an Hashtags binden? Gibt es dazu eine Passage in der Doku?
    Zitat von mermshaus
    Es gibt das hier:

    Code:
    {
        "require": {
            "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
            "acme/foo": "1.0.x-dev#abc123"
        }
    }


    - https://getcomposer.org/doc/04-schema.md#package-links
    - http://stackoverflow.com/questions/2...would-be-avail

    Ich muss aber eingestehen, dass ich das nicht meinte, als ich meine anderen Posts geschrieben habe.

    Ich hatte das hier im Kopf:

    Code:
    {
        "repositories": [
            {
                "type": "package",
                "package": {
                    "name": "geshi/geshi",
                    "version": "1.0.8",
                    "dist": {
                        "url": "https://github.com/GeSHi/geshi-1.0/archive/c5329d9b39a3e07f2745d1f1dbb3d389657c01e7.zip",
                        "type": "zip"
                    },
                    "autoload": {
                        "classmap": ["src/"]
                    }
                }
            }
        ],
        "require": {
            "geshi/geshi": "1.0.*"
        }
    }
    Das nutzt allerdings kein Git (also auch kein Git, was die Daten validieren würde), bindet aber trotzdem einen Commit-Hash, wenn man dem GitHub-URL und GitHub insgesamt vertraut (und wenn niemand die eigene Verbindung gehijackt hat). Das ist aber halt zufällig/vendor-spezifisch so, weil es bei GitHub eben geht.

    Ich hatte aber einfach so angenommen, dass das auf die Weise (also mit expliziten Commits) auch mit einem Git-Pull/-Clone/-Whatever funktionieren würde. (Sorry.)

    Das kann ich aber derzeit weder widerlegen noch bestätigen, weil ich auch keine ordentliche Doku dazu finde. Es gibt ja VCS-Typen für Package-Definitionen in der composer.json.

    Code:
        "repositories": [
            {
                "type": "package",
                "package": {
                    "name": "smarty/smarty",
                    "version": "3.1.7",
                    "dist": {
                        "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
                        "type": "zip"
                    },
                    "source": {
                        "url": "http://smarty-php.googlecode.com/svn/",
                        "type": "svn",
                        "reference": "tags/Smarty_3_1_7/distribution/"
                    },
                    "autoload": {
                        "classmap": ["libs/"]
                    }
                }
            }
        ],
    - https://getcomposer.org/doc/05-repos...s.md#package-2

    Was da mit dem reference-Attribut so geht oder ob sich auf andere Weise ein Commit gezielt spezifizieren lässt, weiß ich aber nicht.

    Passenderweise ist dort Smarty das Beispiel. Das macht das jetzt doch viel weniger offtopic.

    Ab hier neu.

    Gerade das hier versucht:

    Code:
    {
        "repositories": [
            {
                "type": "package",
                "package": {
                    "name": "acoon/wowarmoryapi",
                    "version": "4.0.2",
                    "source": {
                        "url": "git://git.code.sf.net/p/wowarmoryapi/code",
                        "type": "git",
                        "reference": "b0086c39ca0e231e52046b512d44c274d25fc8cf"
                    },
                    "autoload": {
                        "classmap": [""]
                    }
                }
            }
        ],
        "require": {
            "acoon/wowarmoryapi": "4.0.*"
        }
    }
    - http://sourceforge.net/projects/wowarmoryapi/

    b0086c39 ist der Hash des Tags 4.0.2. (Ob man den Tag auch namentlich angeben kann, habe ich nicht versucht. War mir egal.)

    Code:
    $ cd vendor/acoon/wowarmoryapi/ && git log -1 && cd -
    commit b0086c39ca0e231e52046b512d44c274d25fc8cf
    Author: Thomas Andersen <acoon@users.sourceforge.net>
    Date:   Wed Oct 8 13:40:22 2014 +0200
    
        Added: character->getCombatPets()
    Das scheint hinzuhauen. Das Quell-Repo ist jedenfalls mittlerweile einige Commits weiter als b0086c39.

    Blöd ist nur, dass das im JSON unter dem Key package.source steht. package.dist wäre besser, um nicht das .git-Zeug (also die VCS-Metadaten) im vendor-Verzeichnis zu haben. Das scheint aber wohl by design zu sein, da das mit type=git wohl nicht anders geht.

    Code:
      [LogicException]                                                             
      Downloader "Composer\Downloader\GitDownloader" is a source type downloader   
      and can not be used to download dist
    Das Ziel ist es sozusagen, den Inhalt eines beliebigen Git-Repositories zu einem bestimmten Commit als dist-Package in Composer einzubinden. ("dist" – benutze ich hier etwas generisch – meint eben: ohne die Metadaten des Versionskontrollsystems. Bei SVN heißt das glaube ich „export“. http://stackoverflow.com/questions/1...ike-svn-export)

    Wem dazu irgendwas einfällt oder wer sonstige Anmerkungen und dergleichen hat: Das wird alles gerne genommen.

    (Falls jemand weiß, ob SourceForge irgendwo entsprechende Zips/Tars/… von Releases anbietet, die sich verlässlich/robust downloaden lassen, würde mich das auch interessieren. Auf mich wirkt das Interface so, als würden sie das aktiv vermeiden, um Werbung anzeigen zu können. Ich habe bei den Direkt-URLs einfach mal angenommen, dass die im Zweifel nicht ewig gültig sind.)

  • #2
    Zitat von mermshaus Beitrag anzeigen
    (Falls jemand weiß, ob SVN irgendwo entsprechende Zips/Tars/… von Releases anbietet, die sich verlässlich/robust downloaden lassen, würde mich das auch interessieren. Auf mich wirkt das Interface so, als würden sie das aktiv vermeiden, um Werbung anzeigen zu können. Ich habe bei den Direkt-URLs einfach mal angenommen, dass die im Zweifel nicht ewig gültig sind.)
    Du meinst eher Sourceforge, oder? Svn selbst baut keine ZIP-Versionen seines Repos in den eigenen Repos. Und bei Source-Force gibt es die Mirrors (die Direct-Links). Vielleicht kann man darüber direkt auf die Files zugreifen. Das sind dann aber mehr die Download-Versionen. Besser ist vielleicht, wenn jemand von den angebotenen Softwarepackages ein Github-Repos anlegt (wenn die Lizenz das hergibt).

    Zitat von mermshaus Beitrag anzeigen
    Bei SVN heißt das glaube ich „export“.
    Ich habe auf die schnelle jetzt das hier gefunden.

    Kommentar


    • #3
      Zitat von rkr Beitrag anzeigen
      Du meinst eher Sourceforge, oder?
      Ja, danke. Fixed.

      Besser ist vielleicht, wenn jemand von den angebotenen Softwarepackages ein Github-Repos anlegt (wenn die Lizenz das hergibt).
      Joa, wobei das auch blöd ist, weil man, wenn man so was machen könnte und würde, dann im Maintaining drinhängt beziehungsweise in der Verantwortung, die weitere Quelle aufrechtzuerhalten, was irgendwie auch nicht unbedingt das ist, worauf man scharf ist.

      Ich habe auf die schnelle jetzt das hier gefunden.
      Bleibt halt das Problem, Composer beibringen zu wollen, so was durchzuführen. Vielleicht geht das mit irgendwelchen Hooks. Ich mag aber in der Regel keine Hooks. Finde, die verkomplizieren immer alles. (Man kann natürlich auch vor dem Deployment einfach die .git-Verzeichnisse rauslöschen. Aber das ist schon unsauber und vermutlich auch nicht rein damit getan.)

      Ich bin mir aber ohnehin nicht wirklich sicher, ob es überhaupt im Sinne des Erfinders wäre, einen „dist type downloader“ zu haben, der das Repo holt, einen bestimmten Commit auscheckt und exportiert und die entstandenen Dateien dann ins vendor-Verzeichnis verschiebt und den Rest löscht.

      In vielen Fällen wird das vermutlich funktionieren und auch das sein, was man will. Aber ich habe da einerseits wieder Angst vor Hooks, die im git-Repo drinhängen könnten und bei onclone und dergleichen triggern und wer weiß was anstellen könnten. (Habe jetzt nicht recherchiert, ob es so was gibt. Wie gesagt, ich meide Hooks, wo es geht.) Und andererseits ist es wohl nicht immer damit getan, nur die Dateien zu exportieren, um aus einem Repository-Zustand eine Release-Version eines Packages zu machen.

      Letztlich dürfte es wirklich der zu präferierende Weg sein, Druck auf den Autor der Software auszuüben, das Zeug auf Packagist oder dergleichen zu packen. Aber wahnsinnig befriedigend finde ich das auch nicht. Ich hätte da schon gern eine flexiblere Lösung, bei der man sich das Zeug einfach krallen kann, wie man es braucht.

      Kommentar

      Lädt...
      X