Kunnen distutils een afhankelijkheidscontrole uitvoeren zonder te installeren?

Is het mogelijk om distutils alleen de afhankelijkheidsanalyse van de python-module te laten uitvoeren (en mogelijk ontbrekende modules te installeren) zonder de betreffende python-module daadwerkelijk te installeren? Ik stel me een commando als volgt voor:

./setup.py check-dependencies

die zou rapporteren als er afhankelijke modules ontbreken op het doelsysteem.

4

3 antwoord

Dependencies in Python packaging are a confusing subject. For a long time, the only standard was PEP 314, which defines the requires, provides and obsoletes parameter to the distutils.core.setup function. The elements used for these arguments are Python module name, for example provides=['xml', 'xml.utils']. The PEP was not very clear about standard library dependencies (do I have to depend on Python >= 2.5 or do I have to require 'xml'?) and as it turned out, there was no tool that made use of these fields (not even distutils itself).

Toen kwamen setuptools. Het introduceerde andere soorten afhankelijkheden die project namen gebruikten in plaats van modules , dus je kunt bijvoorbeeld instellen (..., install_requires = ['PyXML', 'Pylons'], tests_require = ['nose']) , wat enorm veel nuttiger is: mensen geven software vrij op PyPI met unieke projectnamen, en je kunt dezelfde namen in je setup-script gebruiken om ervan af te hangen, en met easy_install of pip krijg je deze afhankelijkheden geïnstalleerd, modules, scripts en zo.

Toen de teugels van distutils een paar jaar geleden opnieuw werden opgenomen, heeft de community een aantal van de afhankelijke elementen van setuptools gestandaardiseerd om PEP 345 te produceren, dat nu wordt geïmplementeerd in distutils2, bedoeld om distutils en setuptools te vervangen.

Om het allemaal samen te vatten: - misschien heb je in de hele wereld afhankelijkheden op module-niveau in je setup-script, die nutteloos zijn - mogelijk hebt u set-ups op stijlniveau, die worden gebruikt door op setuptools gebaseerde hulpprogramma's - u kunt PEP 345-compatibele project-deps gebruiken in een setup.cfg -bestand, die worden gebruikt door distutils2

Dus om ons uw vraag te laten beantwoorden, moet u ons vertellen welke soort u heeft. Voor alle praktische zaken, zouden de module-deps in de stijl van distutils niet moeten worden gebruikt, dus het laat setuptools project-deps of de nieuwe PEP 345-stijl over, die nog nieuw en nog niet wijdverspreid zijn. distutils2 heeft een compatibiliteitslaag voor setuptools, dus het kan mogelijk zijn om het te gebruiken om de gewenste info uit een op setuptools gebaseerd script setup.py te halen.

Niet gerelateerd aan verpakkingsgereedschap, er is ook een tool die uw code kan scannen om de modules te vinden die u gebruikt: het is de modulezoekermodule in de standaardbibliotheek, die niet erg bekend of gebruikt is, te oordelen naar de trieste status van de code . Deze tool zal je niet vertellen of een gebruikte module afkomstig is van het stdlib of een project van een derde partij, en het kan je niet vertellen welke projectnaam gebruikt moet worden in je setup.py of setup.cfg bestand.

HTH

5
toegevoegd
Ik gebruik install_requires.
toegevoegd de auteur Raffi Khatchadourian, de bron
Dus je vraagt ​​naar projectafhankelijkheden, geen modules. setup-scripts hebben zoekopties voor metadata, zoals python setup.py --name ; helaas ondersteunt setuptools python setup.py --install-requires niet.
toegevoegd de auteur Éric Araujo, de bron

Ik denk dat het dichtstbijzijnde wat je kunt krijgen is:

setup.py install -v -n

wat betekent om een ​​dry-run ( -n ) in de uitgebreide ( -v ) modus uit te voeren.

U zou ook de module distuitls.dep_util kunnen gebruiken. Het werkt echter niet als een optie van setup.py .

HTH!

3
toegevoegd
--dry-run (-n) heeft het gedaan. Bedankt!
toegevoegd de auteur Raffi Khatchadourian, de bron
Dat is geluk, want de droogloopmodus is voor sommige opdrachten verbroken. (Ik zal werken aan het oplossen van dat, maar het is niet triviaal om unit tests voor het gefixeerde gedrag te schrijven).
toegevoegd de auteur Éric Araujo, de bron

distutils.dep_util maakt zich zorgen over bestandsafhankelijkheden (dat wil zeggen als somefile.c nieuwer is dan somefile.o, dan moet somefile.o opnieuw worden gecompileerd), niet projectafhankelijkheden. [wilde dit toevoegen als een reactie op het andere antwoord, maar blijkbaar voegt de knop Reactie toevoegen een antwoord toe?]

0
toegevoegd
Hm, commentaar toevoegen zou een opmerking moeten toevoegen aan het antwoord.
toegevoegd de auteur Raffi Khatchadourian, de bron