Pipenv: Bagaimana cara agar setup.py install_requires dan Pipfile tetap sinkron

Apakah pipenv memiliki API python yang dapat digunakan? Saya memperbarui daftar secara manual saat saya mengerjakan sebuah proyek tetapi yang berikut ini mungkin bagus:

from setuptools import setup
from pipenv import find_install_requires

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

fungsi hanya perlu mengembalikan daftar kunci di bagian [paket] pipfiles. Saya membayangkan Anda dapat mencapai fungsi ini dengan menggunakan fungsi pembantu, tetapi alangkah baiknya jika itu adalah bagian dari pipenv jadi kita tidak semua harus mengimplementasikannya.

Pipfile , implementasi yang mendukung penguraian Pipfile Pipenv, dapat membantu dengan ini:

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

Tapi saya tidak akan merekomendasikan ini, atau tergantung pada Pipenv di setup.py. Mengimpor pipenv (atau pipfile ) berarti pengguna harus benar-benar menginstalnya sebelum mencoba menginstal paket Anda, dan alat seperti Pipenv mencoba mengintip ke dalamnya tanpa menginstal ( setup.py egg_info ) menang tidak bekerja. Setup.py seharusnya hanya bergantung pada Setuptools.

Solusi jalan tengah adalah dengan menulis alat yang mirip dengan bumpversion yang secara otomatis menyinkronkan file teks berdasarkan Pipfile. Distribusikan file ini dengan paket Anda, dan baca di setup.py. Kemudian gunakan CI atau kait komit untuk memastikan file selalu sinkron.

Ya poin bagus abaikan saya.
Mungkin "pipenv install" dapat melakukan sinkronisasi?

Pada Senin, 8 Jan 2018 pukul 17:04, Tzu-ping [email protected]
menulis:

Pipfile https://github.com/pypa/pipfile , implementasi mendukung
parsing, dapat membantu dengan ini:

impor pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
cetak(pf.data['default'])

Tapi saya tidak akan merekomendasikan ini, atau tergantung pada Pipenv di setup.py.
Mengimpor pipenv (atau pipfile) berarti pengguna harus benar-benar menginstal
bahwa sebelum mencoba menginstal paket Anda, dan alat seperti Pipenv mencoba
mengintip ke dalamnya tanpa menginstal (setup.py egg_info) tidak akan berfungsi. Itu
setup.py seharusnya hanya bergantung pada Setuptools.

Solusi jalan tengah adalah dengan menulis alat yang mirip dengan bumpversion
https://github.com/peritus/bumpversion yang secara otomatis menyinkronkan teks
file berdasarkan Pipfile. Bagikan file ini dengan paket Anda, dan bacalah
di setup.py. Kemudian gunakan CI atau kait komit untuk memastikan file selalu
dalam sinkronisasi.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr baru saja menguji asumsi saya di sini, tetapi tidakkah mungkin menambahkan pipenv ke setup.py's setup_requires, dan menunda impor pipenv ke Perintah setuptools? Atau apakah itu dianggap praktik yang buruk?

@Korijn Ini mungkin tidak per se, tetapi mengingat praktik terbaik saat ini adalah menggunakan virtualenvs terpisah untuk setiap proyek Python, ini akan mengharuskan pengguna untuk menginstal salinan Pipenv untuk setiap proyek, yang tidak terlalu intuitif. Pipenv hanya boleh diinstal sekali (biasanya secara global), dan digunakan di luar virtualenv proyek untuk mengelolanya, bukan di dalam virtualenv proyek.

Jadi apa resolusi untuk ini yang menyebabkan penutupan masalah? Apakah tidak ada cara untuk melacak kedua dependensi di Pipfile dan di setup.py ? Apakah ada praktik terbaik yang menghindari masalah?

Untuk aplikasi yang di-deploy atau didistribusikan di installer, saya hanya menggunakan Pipfile.

Untuk aplikasi yang didistribusikan sebagai paket dengan setup.py, saya meletakkan semua dependensi saya di install_requires.

Kemudian saya membuat Pipfile saya bergantung pada setup.py dengan menjalankan pipenv install '-e .' .

[Pembaruan 23-08-2019] Saya menyimpan paket dev di Pipfile saat ini, hanya dependensi runtime yang bisa hidup di setup.py.

Saya pikir pendekatan @ Korijn adalah praktik terbaik di sini. Pipfile (dan requirements.txt) adalah untuk aplikasi; setup.py adalah untuk paket. Mereka melayani tujuan yang berbeda. Jika Anda perlu menyinkronkannya, Anda salah melakukannya (IMO).

@uranusjr Tidak sesuai dengan dokumentasi.

Pipenv adalah alat yang bertujuan untuk menghadirkan yang terbaik dari semua dunia pengemasan (bundler, komposer, npm, kargo, benang, dll.) ke dunia Python. Windows adalah warga negara kelas satu, di dunia kita.

Ini secara otomatis membuat dan mengelola virtualenv untuk proyek Anda, serta menambah/menghapus paket dari Pipfile Anda saat Anda menginstal/menghapus paket. Itu juga menghasilkan Pipfile.lock yang sangat penting, yang digunakan untuk menghasilkan build deterministik.

Mungkin aku hanya tidak mengerti. Bisakah Anda menguraikan pernyataan Anda?

Cara saya memahaminya adalah bahwa pipenv adalah sistem manajemen ketergantungan lengkap yang mirip dengan komposer untuk PHP, tetapi saya mulai menyadari bahwa itu bukan. Terutama karena pipenv tidak akan menginstal dependensi dari dependensi yang memiliki Pipfile dan Pipfile.lock, tetapi tidak ada install_requirements di setup.py.

@vascowhite pertanyaan yang Anda tanyakan bukan tentang pipenv melainkan tentang pemisahan mendasar antara alat pengemasan python. Dalam alur kerja python, file setup.py digunakan untuk mendeklarasikan dependensi instalasi dari paket yang dapat didistribusikan. Jadi, jika saya memiliki paket seperti requests , dan itu tergantung pada orang yang menginstal cffi , saya akan mendeklarasikannya di setup.py saya sehingga ketika orang menjalankan pip install requests itu akan melakukan instalasi itu jika perlu juga.

Pipfiles, seperti file persyaratan, tidak dimaksudkan untuk dilalui secara rekursif. Alih-alih, ada satu pipfile yang mengatur semua dependensi untuk proyek yang mungkin Anda kembangkan. Intinya adalah bahwa alur kerja lama menghasilkan daftar persyaratan yang disematkan, sementara Pipfiles berisi persyaratan tingkat atas dan lebih suka tidak disematkan jika memungkinkan. Saat Anda menginstal sebuah paket, persyaratan dari setup.py itu diselesaikan secara rekursif ke kecocokan terbaik yang juga sesuai dengan persyaratan Anda yang lain.

Jadi jika Anda ingin tahu mengapa Pipfiles tidak diselesaikan secara rekursif, itu karena bukan itu yang digunakan dalam python. Menjalankan pipenv install pada akhirnya membutuhkan target yang dapat diinstal oleh setuptools , yang berarti persyaratan pemasangannya akan ditentukan dalam file pengaturannya.

@techalchemy Saya sudah setengah jalan melalui respons yang sama sebelum Anda muncul 😂 (hapus semuanya)

Saya juga ingin mencatat bahwa @vascowhite yang Anda tanyakan sebenarnya tidak aneh. Dengan Pipfile dan file kunci keduanya tersedia, dimungkinkan untuk merekonsiliasi dua alur kerja yang berbeda. Di dunia yang ideal, Pipfile menggantikan install_requires setup.py, dan digunakan untuk menentukan dependensi virtual, sedangkan file kunci digunakan untuk menghasilkan kumpulan dependensi konkret berdasarkan itu, menggantikan requirements.txt.

Sistem pengemasan Python, bagaimanapun, jauh dari ideal saat ini, dan itu akan membutuhkan banyak pembersihan sebelum ini bisa terjadi. Heck, Pipenv sudah mengalami kesulitan menangani dependensi sekarang (ps bukan salah siapa-siapa), itu mungkin hampir tidak akan berfungsi kecuali untuk proyek yang paling sederhana jika digunakan seperti itu.

Harapannya tidak hilang (setidaknya bukan milikku). Ada banyak PEP yang diusulkan dan diterapkan di sekitar masalah ini, dan saya merasa semuanya berada di jalur yang benar dengan setup.py dan requirements.txt keduanya bergerak menuju format deklaratif yang kaku. Dengan ekosistem yang begitu besar, segala sesuatunya perlu bergerak lambat (atau lihat Python 3.0), tetapi memang bergerak.

@techalchemy @uranusjr
Terima kasih atas jawaban Anda yang jelas, mereka meluruskan beberapa hal dalam pikiran saya. Tampaknya bagi saya bahwa dokumentasi sudah selesai menyatakan apa yang dapat dilakukan Pipenv dan itu sebagian merupakan penyebab kebingungan saya. Sebagian besar kebingungan saya ada pada saya :)

Berasal dari PHP, saya bingung dengan pengemasan dalam python, Komposer sangat mudah dibandingkan. Saya menemukan python jauh lebih mudah untuk dikembangkan dan suka menggunakannya. Mari berharap keadaan membaik, saya yakin mereka akan memberikan upaya dari orang-orang seperti Anda dan Kenneth Reitz.

Jika Anda tetap berpegang pada saran saya yang disebutkan di atas, Anda dapat menyelaraskan setup.py dan pipenv dengan sempurna. Tidak perlu rewel semua. :)

sepertinya bukan saya saja yang bingung #1398

Letakkan jauh lebih baik daripada yang saya bisa :)

Datang ke sini untuk info tentang menggunakan pipenv dengan setup.py ; menambahkan .2 sen saya ke diskusi.

Saya memiliki paket python yang setup.py terlihat seperti:

 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'
        ]
    }

Seperti yang Anda lihat, saya menggunakan click di titik masuk skrip untuk tugas-tugas seperti membangun dan menerapkan.

Ketika saya menjalankan $ my-pkg-name-cmdline build saya tidak menemukan click terinstal, karena pipenv install --dev menginstal paket di pipenv virtualenv. Saya perlu mengutak-atik pipenv shell/exit untuk membuatnya bekerja. Sepertinya masih ada beberapa sisi kasar dalam hal ini.

Oleh karena itu +1 untuk tidak menggunakan pipenv untuk paket.

Saya pikir Anda diharapkan untuk memanggil pipenv run my-pkg-name-cmdline build dalam skenario itu.

@Korijn Saya masih tidak yakin tentang alur kerja yang benar (masih bereksperimen sedikit dengan pipenv).

Sampai saat ini, alur kerja yang tampaknya berfungsi untuk saya adalah:

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

Sekarang saya dapat menjalankan skrip paket click dari baris perintah.

jika saya masuk ke virtualenv (langkah 4) sebelum menginstal aplikasi secara lokal (langkah 3), tidak berfungsi.

Mungkin saya hanya perlu mengatur ulang otak saya untuk mengingat bahwa paket harus diinstal sebelum pipenv shell (saat menggunakan virtualenv mengharuskan Anda menginstal paket dengan virtualenv diaktifkan).

@apiraino Saya pikir Anda tidak mengerti apa-apa di sini. Jika Anda ingin menggunakan (impor) klik dalam paket Anda, Anda harus meletakkannya di install_requires sebagai gantinya, sehingga orang (termasuk Anda) yang menginstal paket Anda dapat menginstal klik juga. Menempatkannya di extras_require['dev'] berarti ketergantungan opsional, yaitu paket Anda dapat bekerja tanpanya, tetapi menginstal tambahan tersebut dapat memberikan fitur tambahan tertentu.

Diskusi ini benar-benar tidak ada hubungannya dengan Pipenv lagi. Saya sarankan Anda membawa masalah ini ke forum yang lebih cocok, seperti StackOverflow atau milis terkait Python.

@Korijn pipenv install '-e .' menghasilkan Pipfile tidak mencerminkan modul yang terdaftar di bawah install_requires di setup.py

Ini masih berlaku untuk pipenv 9.0.3.

Bagaimana saya bisa menghasilkan Pipfile dari setup.py 's install_requires saya?

jangan pakai tanda petik

Saya berhenti menggunakan tanda kutip. Namun, saya tidak mendapatkan Pipfile dibuat yang menyertakan deps dari install_requires bagian dari setup.py .

@benjaminweb Saya bingung dengan hal yang sama hari ini. Namun, saya mulai berpikir bahwa perilaku saat ini mungkin benar.

@techalchemy disebutkan di atas itu

Pipfiles berisi persyaratan tingkat atas dan lebih memilih unpinned jika memungkinkan. Saat Anda menginstal sebuah paket, persyaratan dari setup.py-nya diselesaikan secara rekursif ke pencocokan terbaik yang juga sesuai dengan persyaratan Anda yang lain.

Jika Anda menggunakan alur kerja yang disebutkan di https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555, saat Anda menjalankan pipenv install '-e .' pada proyek tanpa Pipfile yang ada, pipenv menghasilkan Pipfile baru dengan pengikut:

[packages]

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

Dalam kasus ini, satu-satunya paket yang Anda minta secara eksplisit untuk diinstal ke dalam virtualenv adalah paket itu sendiri (yaitu "."), jadi masuk akal jika hanya "." ditambahkan ke ( [packages] ) di Pipfile. Demikian pula, jika Anda pipenv install requests , tidak ada ketergantungan install_requires dari request's setup.py yang ditambahkan ke Pipfile proyek Anda juga.

Namun, ketika langkah penginstalan paket terjadi selanjutnya, dependensi install_requires akan diinstal sebagai bagian dari resolusi dependensi untuk paket tersebut .

Perhatikan bahwa tidak seperti Pipfile, Pipfile.lock mencatat semua dependensi yang tepat untuk seluruh virtualenv, yang harus menyertakan dependensi install_requires yang dikunci ke versi tertentu. Jika Anda melihat Pipfile.lock yang dihasilkan, Anda akan melihat dependensi install_requires terdaftar.

Mungkin saya benar-benar salah paham bagaimana ini diharapkan bekerja. Mungkin @techalchemy atau @uranusjr dapat mengonfirmasi apakah ini cara berpikir yang benar tentang ini?

Garis pemikiran Anda cocok dengan saya. Saya juga akan menyebutkan bahwa dengan kemajuan dan alat Setuptools baru-baru ini seperti Flit Anda masih dapat menentukan dependensi paket Anda dalam bentuk TOML yang bagus (bukan string persyaratan di setup.py, yang memang tidak terlalu cantik). Anda cukup menentukannya di pyproject.toml sebagai gantinya Pipfile.

@uranusjr sepertinya yang Anda katakan adalah bahwa Pipfile hanya perlu secara eksplisit mencantumkan dependensi proyek jika belum ditangkap oleh alat pengemasan seperti Setuptools atau Flit (melalui setup.py atau pyproject.toml)

Misalnya, jika setup.py terlihat seperti:

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

Maka Pipfile hanya membutuhkan yang berikut ini:

[[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}

Menjalankan pipenv install akan menginstal dependensi A untuk produksi, dan pipenv install --dev akan menginstal dependensi A & B untuk pengembangan.

Jika seseorang sudah menggunakan Setuptools atau Flit, apakah pernah ada alasan mengapa dependensi harus ditambahkan ke Pipfile di bawah [packages] atau [dev-packages] ? Melihat Permintaan sebagai contoh, tidak jelas bagi saya mengapa dependensi pengembangan terdaftar secara eksplisit di Pipfile di bawah [dev-packages] , tetapi dependensi install_requires dan test_requirements semuanya ditangkap dalam pengaturan .py.

Sepertinya satu-satunya alasan mengapa Anda perlu menambahkan dependensi secara eksplisit ke Pipfile adalah jika Anda tidak menggunakan Setuptools atau Flit. Apakah ini benar? Apakah ada alasan mengapa ini tidak benar?

Saya pikir itu hanya preferensi pribadi. Mencantumkan dependensi dev di extras_require[dev] hanyalah sebuah konvensi; dev-packages OTHO adalah kunci yang terdefinisi dengan baik. extras_require[dev] juga akan memungkinkan pengguna mana pun untuk pip install package[dev] , yang mungkin tidak disukai oleh pengelola. Saya dapat memahami orang-orang lebih memilih salah satu dari yang lain.

Adapun packages , tidak, sebenarnya tidak ada skenario yang lebih masuk akal daripada install_requires IMO. Saya yakin orang akan datang dengan penggunaan kreatif sekalipun.

Mengapa masalah ini ditutup?

@JulienPalard ditutup karena beberapa alasan:

1. Pipfiles dan file setup.py tidak benar-benar dimaksudkan untuk disinkronkan, pada dasarnya, saya pikir ada banyak artikel yang ditautkan membahas detailnya tetapi tl;dr Pipfile kira-kira setara dengan a tingkat atas requirements.txt
2. Jika Anda ingin proyek Anda (misalnya direktori saat ini) memiliki setup.py yang diselesaikan ke virtualenv terkelola, alur kerjanya hanya pipenv install -e . -- ini menempatkan satu entri ke dalam Pipfile Anda Pipfile.lock Anda termasuk install_requires yang diselesaikan. Jika Anda ingin memperbarui virtualenv dengan konten terbaru karena install_requires , Anda harus menjalankan pipenv update yang sama dengan pipenv lock && pipenv sync di versi terbaru.

Semoga ini bermanfaat!

Sebenarnya mereka lebih mirip dari Pipfile mirip dengan requirements.txt : requirements.txt menentukan semua paket dengan cara yang datar sementara Pipfile & setup.py hanya membutuhkan dependensi entry level. Pipfile.lock & requirements.txt berisi info serupa.

Saya membuat skrip sinkronisasi POC yang dapat diimplementasikan lebih lanjut tetapi saat ini mencakup kasus penggunaan kami:
https://Gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan pada dasarnya itulah yang saya katakan, masing-masing hal ini mewakili daftar tingkat atas dari dependensi Anda, tetapi satu dimaksudkan untuk _menginstal aplikasi_ ( setup.py ) dan yang lainnya dimaksudkan untuk _mengembangkannya_ ( Pipfile ).

Dalam kasus sebelumnya menggunakan setup.py , Anda memiliki opsi yang sama untuk mendeklarasikan dependensi terbuka atau disematkan sepenuhnya seperti yang Anda lakukan dengan requirements.txt , tetapi kebanyakan orang menggunakan penyematan dependensi terbuka di sini. Dalam Pipfile Anda dapat menentukan pin ketat atau longgar juga, tetapi disarankan untuk menyimpan ini sebagai daftar _unflattened_ dari grafik ketergantungan Anda. Sekali lagi, saya ingin menekankan bahwa kedua hal ini juga sepenuhnya valid dalam file requirements.txt , itulah sebabnya saya terus menekankan pemisahan tanggung jawab antara aplikasi dan perpustakaan. Anda akan mendengar penekanan ini dalam setiap pembicaraan dan setiap tutorial dan dalam semua pesan yang dikeluarkan oleh PyPA.

Pipfile.lock dan requirements.txt bukanlah hal yang sama. Anda dapat menghasilkan requirements.txt yang valid dari Pipfile.lock , tetapi Anda tidak dapat secara langsung membuat file kunci dari file persyaratan tanpa menggunakan perantara Pipfile . Itu karena Pipfile.lock mewakili penutupan transitif dan akan selalu membutuhkan perantara Pipfile untuk melakukan resolusi ketergantungan.

Mengenai pertanyaan awal, tidak ada alasan untuk menyinkronkan file setup.py dengan Pipfile selain hanya dengan memasukkan direktori yang dimaksud sebagai jalur yang dapat diedit. Saat Anda menjalankan pipenv lock , dependensi dalam file setup.py akan diselesaikan secara otomatis. Saya tidak yakin tentang kasus penggunaan khusus Anda, @iddan , atau mengapa Anda perlu memiliki pengurai khusus untuk menulis kembali ke file pengaturan, tetapi saya menduga Anda mungkin ingin membaca artikel Donald Stufft tentang setup.py vs persyaratan. txt atau untuk referensi komentar ini oleh salah satu pengelola kami tentang perbedaan dan bagaimana hal itu berlaku khusus untuk Pipenv.

Kasus penggunaan saya adalah bahwa di K Health kami memiliki repo dengan paket internal kami yang merupakan layanan mandiri dan juga dapat dikonsumsi sebagai paket. Jadi kami ingin berbagi dependensi tingkat atas kami antara konsumen paket dan konfigurasi dev/deployment layanan. Karena kami menggunakan Pipenv untuk mengelola dependensi kami, akan menyenangkan untuk mendapatkan output dari Pipfile sebagai setup.py

Kedengarannya seperti varian #2148 (mengganti requirements.txt dengan Pipfile).

Tapi ini tentang setup.py

Ini. Masalah. Sebaiknya. Bukan. Menjadi. Tertutup.

Masalah ini ditutup karena

1. Pipenv bukan alat pengemasan .
2. Keputusan telah dibuat untuk tidak menyertakan fungsionalitas pengemasan di Pipenv.
3. Telah dijelaskan bagaimana Anda dapat menggunakan Pipenv untuk mengelola dependensi pengembangan selama pengembangan paket.
4. Pipfile adalah standar terbuka. Sangat mudah untuk membangun alat pengemasan berdasarkan format Pipfile. Fakta bahwa Pipenv memutuskan untuk tidak melakukannya tidak berarti mengecualikan diri Anda dari melakukannya.

Jika Anda benar-benar peduli, tolong, buat alat sendiri. Dengan begitu banyak antisipasi dalam masalah ini, saya yakin tidak akan sulit untuk mendapatkan daya tarik jika Anda memposting solusi Anda di sini. Dan dengan traksi, PyPA dapat merekomendasikannya di panduan pengemasan, seperti halnya Pipenv. Tetapi pertama-tama Anda harus benar-benar membangun alatnya.

Juga harap belajar untuk menangani pengelola proyek dengan hormat. Lihat kode etik untuk referensi. Kami senang melakukan diskusi yang produktif tetapi kami adalah sukarelawan dan kami di sini tidak hanya untuk menuruti keinginan individu. Jika Anda tidak dapat mengelolanya, jangan repot-repot memposting.

Saya akan merekomendasikan mengunci masalah ini untuk mencegah diskusi lebih lanjut. Saya pikir intinya telah dibuat dengan jelas.

Lakukan satu hal dan lakukan dengan baik!

Halo semuanya,

@Korijn saya membaca bagian di mana Anda menjelaskan bagaimana Anda menggunakan extra_requires untuk menyinkronkan setup.py dengan Pipfile.

Saya mencoba melakukan itu dan memperhatikan bahwa Pipfile.lock tidak memiliki paket extra_require di bagian dev, jadi ketika Anda memiliki kode sumber di venv kosong dan lakukan pipenv install --dev , karena Pipfile.lock tidak memiliki persyaratan extra_require pipenv hanya menginstal paket-paket di 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"
        }
    }
}

seharusnya bukan perilaku yang benar yang Pipfile.lock telah lacak paket dev extra_require?

Ya, ini terlihat seperti bug/batasan bagi saya. Anda harus mengajukan bug/masalah terpisah untuk ini.

Saya pikir ada masalah yang dibuka di pelacak tentang masalah ini, meskipun saya tidak dapat menemukannya sekarang. Silakan lakukan pencarian masalah yang ada sebelum membukanya. Terima kasih sebelumnya :)

Ini bukan bug, Anda tidak dapat menggunakan entri basis yang sama beberapa kali dalam pipfile. Jika Anda menentukan ketergantungan di bagian dev dan juga di bagian default, bagian default akan didahulukan apa pun yang terjadi.

Saya akan menjalani eksperimen pemikiran normal saya, tetapi saya tidak punya waktu sekarang, jadi ambil saja kata-kata saya bahwa itu dapat menyebabkan konflik ketergantungan dan kejutan ketika Anda menyebarkan sesuatu dan mengetahui ketergantungan dev Anda menyembunyikan konflik.

@techalchemy jadi bagaimana saya bisa mengelola dependensi dev saya dalam kasus ini? Saya hanya ingin tahu cara menggunakan pipenv dengan cara yang baik

Saya telah memikirkan ini untuk proyek saya sendiri, dan agak menyadari bahwa saya tidak benar-benar membutuhkan perbedaan packages / dev-packages . Bagaimana kalau daftar {editable = true, extras = ["dev"], path = "."} di packages .

lihat paket pengaturan pipenv ini

Ini menyinkronkan pipfile/lockfile ke 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

anda dapat melakukan $ pipenv-setup sync --dev untuk menyinkronkan dependensi pengembangan dengan kebutuhan tambahan. atau $ pipenv-setup sync --pipfile untuk menyinkronkan pipfile sebagai gantinya

dan $ pipenv-setup check untuk melakukan pemeriksaan saja

satu perintah untuk menyelesaikan semuanya

Apakah ada rencana untuk menggabungkan paket pipenv-setup ke pipenv?

@peterdeme

Apakah ada rencana untuk menggabungkan paket pipenv-setup ke pipenv?

@uranusjr @techalchemy Berdasarkan pembahasan di atas, saya pikir pipenv mungkin memiliki filosofi yang agak berbeda. Tetapi jika pengelola setuju, saya ingin mengajukan permintaan tarik dan mencoba mengintegrasikan pipenv-setup

Anda selalu dapat mengurai Pipfile.lock dengan modul json bawaan. Ekstrak dependensi non-dev untuk setup.py install_requires Anda.
Kunci "default" berisi "dicts" bersarang dari nama paket bersama dengan version angka dan markers .
Anda tidak perlu bergantung pada impor eksternal apa pun.

@ Kilo59 Saya telah melihat orang melakukan ini. Tip untuk disebutkan adalah jangan lupa untuk memasukkan Pipfile.lock sebagai data_file di setup.py (atau sertakan di MANIFEST.in). Dan itu untuk lockfile dengan dependensi yang disematkan. pipfile, di sisi lain, tidak sepele untuk diuraikan, jika Anda ingin versi semantik di Pipfile. Persyaratan ketergantungan yang sama dapat ditampilkan dalam berbagai bentuk.

Terima kasih @Madoshakalaka alat Anda berfungsi dengan baik!

Saya setuju dengan rekan-rekan lain bahwa dependensi Setup.py berbeda dari dependensi proyek Pipfile. Tapi tetap saja, memiliki cara yang dapat diprogram untuk menyinkronkannya tanpa tenaga manual adalah fitur penghemat waktu yang hebat. Juga, menghindari kesalahan ketik/kesalahan umum.

setup.py yang menghitam juga merupakan sentuhan yang bagus :+1: