Hi! Thanks for all the useful responses!
I am basically working on libraries that will be distributed on PyPi, such as https://github.com/HDI-Project/BTB/ and https://github.com/HDI-Project/ATM/ (Auto Machine Learning and Model Tuning libraries developed by Data to AI lab, in MIT). It looks like, in this scenario, the setup.py option seems to be the most supported one, so we'll probably go for it! Thanks again! Carles On 07/05/18 09:59, Chris Jerdonek wrote: > What kind of project is it? For example, is it a software library e.g. > to put on PyPI, or a website application for a company to run? The > answer to this question will help people answer your question because > it has a big impact on what practice will be best for you. > > —Chris > > On Sun, May 6, 2018 at 11:54 PM Carles Sala Cladellas > <car...@pythiac.com <mailto:car...@pythiac.com>> wrote: > > Hello here! > > TL;DR: Should I use requirements.txt, or should I have my > dependencies only listed inside setup.py? > > Long version: > > The two most common ways to have dependencies listed in a python > package are either having them listed both in setup.py and > requirements.txt files, or having them only listed in > requirements.txt and then import them using some > `parse_requirements` methods. > > In the projects which I am currently working on there are five > lists of requirements: > - requirements.txt > - requirements_test.txt > - requirements_dev.txt > - install_requires inside setup.py > - tests_require inside setup.py > > I wanted to remove duplicities, so I thought about removing the > setup.py lists and parse the dependencies from the > requirements*.txt files. > > But then I came across this, https://stackoverflow.com/a/28842733, > which recommends using a `dev` entry in `extras_require` and then > using `pip install -e .[dev]` to install them, which could be > easily extended to also have a `pip install -e .[test]`. > > I find this a very clean option, since it reduces the amount of > files the repository and makes setup.py and makes setup.py > self-contained. > > Are any known drawbacks to this approach? Is it a good way to go? > > Regards, > > -- > Carles Sala Cladellas > car...@pythiac.com <mailto:car...@pythiac.com> / +34 666 278 679 > > https://www.pythiac.com > Pythia Consulting - Data Science as a Service > > -- > Distutils-SIG mailing list > distutils-sig@python.org <mailto:distutils-sig@python.org> > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/OQW4VU36WWGESOAYLTV6WWDKX2RKHRD4/ > -- Carles Sala Cladellas car...@pythiac.com / +34 666 278 679 https://www.pythiac.com Pythia Consulting - Data Science as a Service
-- Distutils-SIG mailing list distutils-sig@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/2WHZFYYNY2FKBSCZLSWYIKGSDTHGFXRH/
