Pipenv: So halten Sie setup.py install_requires und Pipfile synchron

Hat pipenv eine Python-API, die verwendet werden könnte? Ich aktualisiere die Liste manuell, während ich an einem Projekt arbeite, aber Folgendes könnte nett sein:

from setuptools import setup
from pipenv import find_install_requires

setup(
    # ...
    install_requires=find_install_requires()
    # ...
)

Die Funktion muss nur eine Liste der Schlüssel im Abschnitt pipfiles [packages] zurückgeben. Ich kann mir vorstellen, dass Sie diese Funktionalität bereits mit einer Hilfsfunktion erreichen könnten, aber es wäre schön, wenn sie Teil von pipenv wäre, damit wir sie nicht alle implementieren müssen.

Pipfile , die Implementierung, die das Pipfile-Parsing von Pipenv unterstützt, kann dabei helfen:

import pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

Aber ich würde das nicht empfehlen, oder abhängig von Pipenv in setup.py. Das Importieren pipenv (oder pipfile ) bedeutet, dass der Benutzer das tatsächlich installieren muss, bevor er versucht, Ihr Paket zu installieren, und Tools wie Pipenv, die versuchen, einen Blick darauf zu werfen, ohne ( setup.py egg_info ) zu installieren, haben gewonnen funktioniert nicht. Die setup.py sollte nur von Setuptools abhängen.

Eine Mittelweglösung wäre, ein Tool ähnlich Bumpversion zu schreiben, das automatisch eine Textdatei basierend auf Pipfile synchronisiert. Verteilen Sie diese Datei mit Ihrem Paket und lesen Sie sie in setup.py. Verwenden Sie dann CI oder einen Commit-Hook, um sicherzustellen, dass die Dateien immer synchron sind.

Ja, guter Punkt, ignoriere mich.
Vielleicht könnte „pipenv install“ die Synchronisierung durchführen?

Am Montag, 8. Januar 2018 um 17:04 Uhr, Tzu-ping Chung [email protected]
schrieb:

Pipfile https://github.com/pypa/pipfile , die Implementierung, die die
parsen, kann dabei helfen:

Pip-Datei importieren
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

Aber ich würde das nicht empfehlen, oder abhängig von Pipenv in setup.py.
Das Importieren von pipenv (oder pipfile) bedeutet, dass der Benutzer tatsächlich installieren muss
das, bevor Sie versuchen, Ihr Paket zu installieren, und Tools wie Pipenv versuchen es
Ein Blick darauf ohne Installation (setup.py egg_info) funktioniert nicht. Der
setup.py sollte nur von Setuptools abhängen.

Eine Mittelweglösung wäre, ein Tool ähnlich Bumpversion zu schreiben
https://github.com/peritus/bumpversion , die automatisch einen Text synchronisiert
Datei basierend auf Pipfile. Verteilen Sie diese Datei mit Ihrem Paket und lesen Sie sie
in setup.py. Verwenden Sie dann CI oder einen Commit-Hook, um sicherzustellen, dass die Dateien immer vorhanden sind
synchron.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr testet hier nur meine Annahmen, aber wäre es nicht möglich, pipenv zu setup_requires von setup.py hinzuzufügen und den pipenv-Import in einen setuptools-Befehl zu verzögern? Oder gilt das als schlechte Praxis?

@Korijn Es ist vielleicht nicht per se so, aber da die derzeitige Best Practice darin besteht, separate virtualenvs für jedes Python-Projekt zu verwenden, müsste der Benutzer für jedes Projekt eine Kopie von Pipenv installieren, was nicht sehr intuitiv ist. Pipenv sollte nur einmal installiert werden (normalerweise global) und wird außerhalb der virtuellen Umgebung des Projekts verwendet, um es zu verwalten, nicht innerhalb der virtuellen Umgebung des Projekts.

Was war also die Lösung, die zur Schließung des Problems geführt hat? Gibt es keine Möglichkeit, sowohl die Abhängigkeiten in Pipfile als auch in setup.py zu verfolgen? Gibt es eine bewährte Methode, die das Problem umgeht?

Für Anwendungen, die in Installern bereitgestellt oder verteilt werden, verwende ich einfach Pipfile.

Für Anwendungen, die als Pakete mit setup.py verteilt werden, lege ich alle meine Abhängigkeiten in install_requires.

Dann mache ich mein Pipfile von setup.py abhängig, indem ich pipenv install '-e .' ausführe.

[Update 2019-08-23] Ich behalte die Dev-Pakete heutzutage in Pipfile, nur die Laufzeitabhängigkeiten leben in setup.py.

Ich denke, der Ansatz von @Korijn ist hier die beste Vorgehensweise. Pipfile (und requirements.txt) ist für Anwendungen; setup.py ist für Pakete. Sie dienen unterschiedlichen Zwecken. Wenn Sie sie synchronisieren müssen, machen Sie es falsch (IMO).

@uranusjr Nicht gemäß der Dokumentation.

Pipenv ist ein Tool, das darauf abzielt, das Beste aus allen Verpackungswelten (Bundler, Composer, npm, Cargo, Garn usw.) in die Python-Welt zu bringen. Windows ist ein erstklassiger Bürger in unserer Welt.

Es erstellt und verwaltet automatisch eine virtuelle Umgebung für Ihre Projekte und fügt Pakete aus Ihrem Pipfile hinzu/entfernt sie, während Sie Pakete installieren/deinstallieren. Es generiert auch die allseits wichtige Pipfile.lock, die zum Erstellen deterministischer Builds verwendet wird.

Vielleicht verstehe ich es einfach nicht. Könntest du deine Aussage bitte präzisieren?

So wie ich es verstanden habe, ist pipenv ein vollständiges Abhängigkeitsverwaltungssystem, ähnlich dem Composer für PHP, aber ich fange an zu erkennen, dass dies nicht der Fall ist. Zumal pipenv nicht die Abhängigkeiten einer Abhängigkeit installiert, die eine Pipfile und Pipfile.lock hat, aber keine install_requirements in setup.py.

@vascowhite Die Frage, die Sie stellen, bezieht sich nicht auf pipenv, sondern auf eine grundlegende Trennung zwischen Python-Paketierungstools. Im Python-Workflow werden setup.py -Dateien verwendet, um Installationsabhängigkeiten eines verteilbaren Pakets zu deklarieren. Also, wenn ich ein Paket wie requests habe und es davon abhängt, dass Leute cffi installiert haben, würde ich das in meinem setup.py deklarieren, damit wenn Leute pip install requests ausführen

Pipfiles sollen wie Anforderungsdateien nicht rekursiv durchlaufen werden. Stattdessen gibt es ein einziges Pipfile, das alle Abhängigkeiten für ein Projekt regelt, das Sie möglicherweise entwickeln. Der Punkt dabei ist, dass der alte Workflow eine abgeflachte Liste von gepinnten Anforderungen generierte, während Pipfiles Anforderungen der obersten Ebene enthalten und nach Möglichkeit nicht gepinnt werden. Wenn Sie ein Paket installieren, werden die Anforderungen von setup.py rekursiv in die beste Übereinstimmung aufgelöst, die auch Ihren anderen Anforderungen entspricht.

Wenn Sie also wissen möchten, warum Pipfiles nicht rekursiv aufgelöst werden, liegt das daran, dass sie in Python einfach nicht so verwendet werden. Das Ausführen pipenv install erfordert letztendlich ein Ziel, das von setuptools installiert werden kann, was bedeutet, dass die Installationsanforderungen in seiner Setup-Datei definiert sind.

@techalchemy Ich war auf halbem Weg durch eine ähnliche Antwort, bevor deine auftauchte 😂 (alles löschen)

Ich möchte auch darauf hinweisen, dass @vascowhite , was Sie fragen, nicht wirklich ausgefallen ist. Da sowohl Pipfile als auch die Sperrdatei verfügbar sind, ist es möglich, die beiden unterschiedlichen Arbeitsabläufe in Einklang zu bringen. In einer idealen Welt ersetzt Pipfile die Datei install_requires setup.py und wird verwendet, um virtuelle Abhängigkeiten anzugeben, während die Sperrdatei verwendet wird, um darauf basierend einen konkreten Abhängigkeitssatz zu erstellen, der die Datei requirements.txt ersetzt.

Das Paketsystem von Python ist derzeit jedoch alles andere als ideal, und es würde eine Menge Aufräumarbeiten erfordern, bevor dies jemals geschehen kann. Verdammt, Pipenv hat bereits jetzt Schwierigkeiten beim Umgang mit Abhängigkeiten (ps, niemand ist schuld), es würde wahrscheinlich kaum funktionieren, es sei denn für die einfachsten Projekte, wenn es so verwendet würde.

Die Hoffnung ist aber nicht verloren (zumindest nicht meine). Zu diesem Thema wurde viel PEP vorgeschlagen und implementiert, und ich glaube, dass die Dinge auf dem richtigen Weg sind, da sich setup.py und requirements.txt beide in Richtung eines starren, deklarativen Formats bewegen. Bei einem so großen Ökosystem müssen sich die Dinge langsam bewegen (oder siehe Python 3.0), aber sie bewegen sich tatsächlich.

@techalchemy @uranusjr
Danke euch beiden für eure klaren Antworten, sie begradigen ein paar Dinge in meinem Kopf. Es scheint mir, dass die Dokumentation zu viel sagt, was Pipenv kann, und das ist teilweise der Grund für meine Verwirrung. Der Großteil meiner Verwirrung liegt jedoch bei mir :)

Da ich von PHP komme, war ich durch das Paketieren in Python verwirrt, Composer ist im Vergleich dazu ein Kinderspiel. Ich finde Python viel einfacher zu entwickeln und liebe es, es zu benutzen. Hoffen wir, dass sich die Dinge verbessern, ich bin sicher, dass sie es angesichts der Bemühungen von Leuten wie Ihnen und Kenneth Reitz werden.

Wenn Sie sich an meine oben genannten Ratschläge halten, können Sie sowohl setup.py als auch pipenv perfekt harmonisieren. Kein Grund, pingelig zu werden. :)

sieht so aus, als wäre ich nicht der einzige, der verwirrt ist #1398

Viel besser ausdrücken als ich könnte :)

Kam hierher für Informationen zur Verwendung pipenv mit einem setup.py ; Hinzufügen meiner 0,2 Cent zur Diskussion.

Ich habe ein Python-Paket, das wie setup.py aussieht:

 setup(                                                                                                     
    name='my-pkg-name',                                                                             
    packages=find_packages(),                                                                              
    install_requires=[...],
    extras_require={
        'develop': ['click']
    },
    entry_points={
        'console_scripts': [
            'my-pkg-name-cmdline = my-pkg-name.cli:tool'
        ]
    }

Wie Sie sehen, verwende ich click im Einstiegspunkt des Skripts für Aufgaben wie Erstellung und Bereitstellung.

Wenn ich $ my-pkg-name-cmdline build ausführe, finde ich click nicht installiert, weil pipenv install --dev Pakete in der virtuellen Umgebung von pipenv installiert. Ich muss mit pipenv shell/exit herumspielen, damit es funktioniert. Sieht so aus, als gäbe es hier noch einige Ecken und Kanten.

Daher +1 für die Nichtverwendung von pipenv für Pakete.

Ich denke, es wird erwartet, dass Sie in diesem Szenario pipenv run my-pkg-name-cmdline build callen.

@Korijn Ich bin mir immer noch nicht sicher über den richtigen Workflow (experimentiere immer noch ein bisschen mit pipenv).

Bisher scheint der Workflow für mich zu funktionieren:

(starting from scratch)
1- pipenv --three
2- pipenv install [--dev]
3- pipenv install -e . (install application locally)
4- pipenv shell (to enter the virtualenv)

Jetzt kann ich mein Paketerstellungsskript click über die Befehlszeile ausführen.

Wenn ich in die virtuelle Umgebung (Schritt 4) eintrete, bevor ich die Anwendung lokal installiere (Schritt 3), funktioniert es nicht.

Vielleicht muss ich mein Gehirn nur neu verdrahten, um mich daran zu erinnern, dass Pakete vor pipenv shell installiert werden sollten (während die Verwendung virtualenv erfordert, dass Sie Pakete mit aktiviertem virtualenv installieren müssen).

@apiraino Ich denke, du verstehst es hier nicht richtig. Wenn Sie Click in Ihrem Paket verwenden (importieren) möchten, sollten Sie es stattdessen in install_requires einfügen, damit Personen (einschließlich Ihnen), die Ihr Paket installieren, Click ebenfalls installiert haben können. Wenn Sie es in extras_require['dev'] , bedeutet dies, dass es sich um eine optionale Abhängigkeit handelt, dh Ihr Paket kann ohne es funktionieren, aber die Installation dieser Extras kann bestimmte zusätzliche Funktionen bereitstellen.

Diese Diskussion hat wirklich nichts mehr mit Pipenv zu tun. Ich schlage vor, Sie bringen dieses Problem in ein geeigneteres Forum, wie z. B. StackOverflow oder Python-bezogene Mailinglisten.

@Korijn pipenv install '-e .' ergibt ein Pipfile , das die unter install_requires in setup.py aufgelisteten Module nicht widerspiegelt

Dies ist immer noch der Fall für pipenv 9.0.3.

Wie kann ich Pipfile aus den install_requires meiner setup.py generieren?

Verwenden Sie keine Anführungszeichen

Ich habe aufgehört, Anführungszeichen zu verwenden. Ich bekomme jedoch kein Pipfile erstellt, das die Deps aus dem Abschnitt install_requires von setup.py enthält.

@benjaminweb Ich war heute von der gleichen Sache verwirrt. Ich fange jedoch an zu glauben, dass sich das aktuelle Verhalten korrigieren könnte.

@techalchemy oben erwähnt

Pipfiles enthalten Top-Level-Anforderungen und werden nach Möglichkeit nicht angeheftet. Wenn Sie ein Paket installieren, werden die Anforderungen aus seiner setup.py rekursiv aufgelöst, um die beste Übereinstimmung zu erzielen, die auch Ihren anderen Anforderungen entspricht.

Wenn Sie den in https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555 erwähnten Workflow verwenden und pipenv install '-e .' für ein Projekt ohne vorhandenes Pipfile ausführen, generiert pipenv ein neues Pipfile mit die folgende:

[packages]

"e1839a8" = {path = ".", editable = true}

In diesem Fall ist das einzige Paket, das Sie ausdrücklich zur Installation in der virtuellen Umgebung angefordert haben, das Paket selbst (dh "."), daher ist es sinnvoll, dass nur "." wird zu ( [packages] ) in der Pipfile hinzugefügt. Wenn Sie pipenv install requests verwenden, werden auch keine der install_requires Abhängigkeiten aus der Datei setup.py der Anfrage zur Pipfile Ihres Projekts hinzugefügt.

Bei der nächsten Paketinstallation werden jedoch die install_requires -Abhängigkeiten als Teil der Abhängigkeitsauflösung für das Paket installiert.

Beachten Sie, dass Pipfile.lock im Gegensatz zu Pipfile alle genauen Abhängigkeiten für die gesamte virtuelle Umgebung aufzeichnet, die die install_requires -Abhängigkeiten enthalten muss, die für bestimmte Versionen gesperrt sind. Wenn Sie sich die generierte Pipfile.lock ansehen, sehen Sie die install_requires -Abhängigkeiten aufgelistet.

Es ist möglich, dass ich völlig missverstehe, wie dies funktionieren soll. Vielleicht können @techalchemy oder @uranusjr bestätigen, ob dies die richtige Denkweise ist?

Deine Denkweise passt zu meiner. Ich möchte auch erwähnen, dass Sie mit den jüngsten Weiterentwicklungen der Setuptools und Tools wie Flit die Abhängigkeiten Ihres Pakets immer noch in netter TOML-Form angeben können (anstelle von Anforderungszeichenfolgen in setup.py, was zugegebenermaßen nicht sehr hübsch ist). Sie geben sie einfach in pyproject.toml anstelle von Pipfile an.

@uranusjr es hört sich so an, als ob Sie sagen, dass Pipfile nur Projektabhängigkeiten explizit auflisten muss, wenn sie nicht bereits von einem Paketierungstool wie Setuptools oder Flit (über setup.py oder pyproject.toml) erfasst werden.

Wenn setup.py beispielsweise so aussieht:

install_requires=['A'],
extras_require={
    'dev': ['B'],
},

Dann braucht das Pipfile nur noch folgendes:

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

"e1839a8" = {path = ".", editable = true}


[dev-packages]

"e1839a8" = {path = ".", extras = ["dev"], editable = true}

Das Ausführen pipenv install würde Abhängigkeit A für die Produktion installieren, und pipenv install --dev würde die Abhängigkeiten A und B für die Entwicklung installieren.

Wenn jemand bereits Setuptools oder Flit verwendet, gibt es einen Grund, warum Abhängigkeiten in die Pipfile unter [packages] oder [dev-packages] hinzugefügt werden sollten? Am Beispiel von Requests ist mir nicht klar, warum die Entwicklungsabhängigkeiten explizit in Pipfile unter [dev-packages] aufgeführt sind, aber die Abhängigkeiten install_requires und test_requirements alle im Setup erfasst werden .py.

Es scheint, dass der einzige Grund, warum Sie Abhängigkeiten explizit zu Pipfile hinzufügen müssten , darin besteht, dass Sie Setuptools oder Flit nicht verwenden. Ist das richtig? Gibt es Gründe, warum das nicht stimmt?

Ich denke, es ist nur eine persönliche Vorliebe. Das Auflisten von Dev-Abhängigkeiten in extras_require[dev] ist lediglich eine Konvention; dev-packages OTHO ist ein wohldefinierter Schlüssel. extras_require[dev] würde auch jedem Benutzer pip install package[dev] ermöglichen, was Betreuern vielleicht nicht gefällt. Ich kann Leute verstehen, die das eine bevorzugen.

Was packages , nein, es gibt wirklich kein Szenario, das sinnvoller ist als install_requires IMO. Ich bin mir sicher, dass die Leute kreative Verwendungen finden werden.

Warum ist dieses Thema geschlossen?

@JulienPalard es ist aus mehreren Gründen geschlossen:

1. Pipfiles und setup.py -Dateien sind per se nicht wirklich dazu gedacht, synchron gehalten zu werden. Ich glaube, es gab eine Reihe von verlinkten Artikeln, in denen die Details besprochen wurden, aber tl;dr Pipfile entspricht ungefähr a oberste Ebene requirements.txt
2. Wenn Sie möchten, dass Ihr Projekt (z. B. das aktuelle Verzeichnis) seine setup.py in die verwaltete virtuelle Umgebung auflöst, wäre der Workflow nur pipenv install -e . – dies fügt einen einzelnen Eintrag in Ihre Pipfile ein Pipfile.lock einschließlich des aufgelösten install_requires . Wenn Sie die virtuelle Umgebung aufgrund eines geänderten install_requires mit den neuesten Inhalten aktualisieren möchten, müssen Sie pipenv update ausführen, was in der neuesten Version mit pipenv lock && pipenv sync identisch ist.

Hoffe, das ist hilfreich!

Eigentlich sind sie ähnlicher als Pipfile requirements.txt ähnlich ist: requirements.txt spezifiziert alle Pakete auf eine flache Weise, während Pipfile & setup.py erfordert nur die Einstiegsabhängigkeiten. Pipfile.lock und requirements.txt enthalten ähnliche Informationen.

Ich habe ein POC-Synchronisierungsskript erstellt, das weiter implementiert werden kann, aber derzeit unseren Anwendungsfall abdeckt:
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan , das ist im Wesentlichen das, was ich gesagt habe, jedes dieser Dinge stellt eine Auflistung der obersten Ebene Ihrer Abhängigkeiten dar, aber eines ist für die _Installation einer Anwendung_ ( setup.py ) und das andere für die _Entwicklung gedacht_ ( Pipfile ).

Im ersten Fall der Verwendung von setup.py haben Sie die gleichen Optionen zum Deklarieren offener oder vollständig gepinnter Abhängigkeiten wie bei requirements.txt , aber die meisten Leute verwenden hier das Pinning von offenen Abhängigkeiten. In einem Pipfile können Sie auch strenge oder lockere Pins angeben, aber es wird gleichermaßen empfohlen, dies als eine _nicht abgeflachte_ Auflistung Ihres Abhängigkeitsgraphen zu behalten. Ich möchte noch einmal betonen, dass diese beiden Dinge auch in requirements.txt -Dateien uneingeschränkt gelten, weshalb ich immer wieder die Trennung der Verantwortlichkeiten zwischen Anwendungen und Bibliotheken betone. Sie werden dies in jedem Vortrag und jedem Tutorial und in allen Nachrichten, die von der PyPA herausgegeben werden, betont hören.

Pipfile.lock und requirements.txt sind nicht dasselbe. Sie können eine gültige requirements.txt aus einer Pipfile.lock generieren, aber Sie können keine Sperrdatei direkt aus einer Anforderungsdatei generieren, ohne einen Vermittler Pipfile zu verwenden. Das liegt daran, dass ein Pipfile.lock einen transitiven Abschluss darstellt und immer einen zwischengeschalteten Pipfile benötigt, um eine Abhängigkeitsauflösung durchzuführen.

Was die ursprüngliche Frage betrifft, gibt es keinen Grund, eine setup.py -Datei mit einer Pipfile $-Datei synchron zu halten, außer einfach das betreffende Verzeichnis als bearbeitbaren Pfad einzufügen. Wenn Sie pipenv lock ausführen, werden die Abhängigkeiten in der Datei setup.py automatisch aufgelöst. Ich bin mir nicht sicher über Ihren spezifischen Anwendungsfall, @iddan , oder warum Sie einen speziellen Parser benötigen, um Dinge in die Setup-Datei zurückzuschreiben, aber ich vermute, Sie möchten vielleicht den Artikel von Donald Stufft über setup.py vs. Anforderungen lesen. txt oder um auf diesen Kommentar von einem unserer Betreuer über die Unterscheidung zu verweisen und wie sie sich speziell auf Pipenv bezieht.

Mein Anwendungsfall ist, dass wir bei K Health ein Repos mit unseren internen Paketen haben, die eigenständige Dienste sind und auch als Pakete konsumiert werden können. Daher möchten wir unsere Abhängigkeiten auf oberster Ebene zwischen den Paketkonsumenten und der Entwicklungs-/Bereitstellungskonfiguration des Dienstes teilen. Da wir Pipenv verwenden, um unsere Abhängigkeiten zu verwalten, ist es schön, eine Ausgabe von Pipfile als setup.py zu erhalten

Klingt nach einer Variante von #2148 (requirements.txt durch Pipfile ersetzen).

Aber hier geht es um setup.py

Dies. Problem. Sollen. Nicht. Sei. Abgeschlossen.

Dieses Thema ist geschlossen, weil

1. Pipenv ist kein Paketierungstool .
2. Es wurde entschieden, Verpackungsfunktionen nicht in Pipenv aufzunehmen.
3. Es wurde klargestellt, wie Sie Pipenv verwenden können, um Entwicklungsabhängigkeiten während der Entwicklung eines Pakets zu verwalten.
4. Pipfile ist ein offener Standard. Es ist einfach, ein Verpackungstool basierend auf dem Pipfile-Format zu erstellen. Die Tatsache, dass Pipenv sich dafür entscheidet, es nicht zu tun, soll Sie nicht davon ausschließen.

Wenn Sie sich wirklich so sehr darum kümmern, machen Sie bitte selbst ein Werkzeug. Bei so viel Vorfreude auf dieses Thema glaube ich, dass es nicht schwierig wäre, Fuß zu fassen, wenn Sie Ihre Lösung hier posten. Und mit Traktion kann PyPA es im Verpackungsleitfaden empfehlen, genau wie Pipenv. Aber zuerst müssen Sie das Tool tatsächlich bauen.

Bitte lernen Sie auch, Projektbetreuer respektvoll anzusprechen. Siehe den Verhaltenskodex als Referenz. Wir freuen uns über produktive Gespräche, sind aber ehrenamtlich tätig und nicht nur dazu da, individuellen Wünschen nachzukommen. Wenn Sie das nicht schaffen, machen Sie sich nicht die Mühe zu posten.

Ich würde empfehlen, dieses Problem zu sperren, um weitere Diskussionen zu verhindern. Ich denke, der Punkt wurde deutlich gemacht.

Mach eine Sache und mach es gut!

Hallo allerseits,

@Korijn Ich habe diesen Teil gelesen, in dem Sie erklärt haben, wie Sie extra_requires verwenden, um setup.py mit Pipfile zu synchronisieren.

Ich habe das versucht und festgestellt, dass Pipfile.lock nicht die extra_require-Pakete im dev-Abschnitt hat, also wenn Sie den Quellcode in einem leeren venv haben und pipenv install --dev ausführen , da Pipfile.lock keine extra_require-Anforderungen hat pipenv installiert nur die Pakete auf install_require .

setup.py

import os  # noqa: D100
from setuptools import setup, find_packages


def read(fname):
    """Read a file and return its content."""
    with open(os.path.join(os.path.dirname(__file__), fname)) as f:
        return f.read()


setup(
    name='auditor_client',
    version='0.0.0',
    description='Auditor client package',
    long_description=read('README.md'),
    packages=find_packages(exclude=['tests']),
    install_requires=['requests==2.9.1'],
    extras_require={'dev': ['flake8', 'flake8-docstrings', 'pytest', 'coverage', 'tox']},
    setup_requires=["pytest-runner"],
    tests_require=["pytest"]
)

Pipfile

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
"e1839a8" = {editable = true, path = "."}

[requires]
python_version = "3.6"

[dev-packages]
"e1839a8" = {editable = true, extras = ["dev"], path = "."}

Pipfile.lock

{
    "_meta": {
        "hash": {
            "sha256": "e58b833e497814c83a2f0b93ad21d33a2af8b72721b20e9607a6c9135978422d"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    },
    "develop": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    }
}

sollte nicht das korrekte Verhalten sein, dass Pipfile.lock extra_require dev-Pakete verfolgt hat?

Ja, das sieht für mich nach einem Fehler/einer Einschränkung aus. Sie sollten dafür einen separaten Fehler/Problem melden.

Ich glaube, dass im Tracker ein Problem zu diesem Problem aufgetreten ist, obwohl ich es im Moment nicht finden kann. Bitte durchsuchen Sie vorhandene Ausgaben, bevor Sie eine öffnen. Vielen Dank im Voraus :)

Dies ist kein Fehler, Sie können denselben Basiseintrag nicht mehrmals in einer Pip-Datei verwenden. Wenn Sie eine Abhängigkeit im dev -Abschnitt und auch im Standardabschnitt angeben, hat der Standardabschnitt in jedem Fall Vorrang.

Ich würde mein normales Gedankenexperiment durchgehen, aber ich habe gerade keine Zeit, also nehmen Sie mich einfach beim Wort, dass es zu Abhängigkeitskonflikten und Überraschungen kommen könnte, wenn Sie etwas bereitstellen und herausfinden, dass Ihre Entwicklerabhängigkeit einen Konflikt verbirgt.

@techalchemy , wie kann ich in diesem Fall meine Entwicklungsabhängigkeiten verwalten? Ich möchte nur wissen, wie man pipenv gut einsetzt

Ich habe für mein eigenes Projekt darüber nachgedacht und irgendwie festgestellt, dass ich die Unterscheidung packages / dev-packages nicht wirklich brauche. Wie wäre es mit {editable = true, extras = ["dev"], path = "."} in packages aufzulisten.

Schauen Sie sich dieses Paket pipenv-setup an

Es synchronisiert pipfile/lockfile mit setup.py

$ pipenv-setup sync

package e1839a8 is local, omitted in setup.py
setup.py successfully updated
23 packages from Pipfile.lock synced to setup.py

Sie können $ pipenv-setup sync --dev tun, um Entwicklungsabhängigkeiten mit zusätzlichen Anforderungen zu synchronisieren. oder $ pipenv-setup sync --pipfile , um stattdessen pipfile zu synchronisieren

und $ pipenv-setup check , um nur Prüfungen durchzuführen

ein Befehl, um sie alle zu lösen 💯

Gibt es einen Plan, das Paket pipenv-setup mit pipenv zusammenzuführen?

@peterdeme

Gibt es einen Plan, das Paket pipenv-setup mit pipenv zusammenzuführen?

@uranusjr @techalchemy Basierend auf der obigen Diskussion denke ich, dass pipenv eine etwas andere Philosophie haben könnte. Aber wenn die Betreuer einverstanden sind, würde ich gerne einen Pull-Request einreichen und versuchen, pipenv-setup zu integrieren

Sie können Pipfile.lock jederzeit mit dem eingebauten Modul json parsen. Extrahieren Sie die non-dev Abhängigkeiten für Ihre setup.py install_requires .
Der Schlüssel "default" enthält verschachtelte „Diktate“ des Paketnamens zusammen mit version Zahlen und markers .
Sie müssen sich nicht auf externe Importe verlassen.

@ Kilo59 Ich habe Leute gesehen, die das tun. Ein zu erwähnender Tipp ist, dass Sie nicht vergessen, Pipfile.lock als data_file in setup.py (oder in MANIFEST.in) aufzunehmen. Und das gilt für Sperrdateien mit fixierten Abhängigkeiten. pipfile hingegen ist nicht trivial zu analysieren, wenn Sie semantische Versionierung in Pipfile wünschen. Dieselbe Abhängigkeitsanforderung kann in mehreren Formen angezeigt werden.

Danke @Madoshakalaka , dein Tool funktioniert gut!

Ich stimme anderen Kollegen zu, dass sich die Abhängigkeiten von Setup.py von den Projektabhängigkeiten von Pipfile unterscheiden. Dennoch ist eine programmierbare Möglichkeit, diese ohne manuelle Arbeit zu synchronisieren, eine großartige zeitsparende Funktion. Vermeidet außerdem Tippfehler/häufige Fehler.

Die geschwärzte setup.py war auch eine nette Geste :+1: