Setup install requirements include libraries only used in utils folder
See original GitHub issueRelated discussion: #195
Should we move the utils folder to its own “side” package? Not everyone will be using the parsers that we have provided, and this might result in them installing packages they don’t need along with Dash Bio.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (9 by maintainers)
Top Results From Across the Web
2. Writing the Setup Script — Python 3.11.1 documentation
The setup script is the centre of all activity in building, distributing, and installing modules using the Distutils. The main purpose of the...
Read more >Is it possible to include subdirectories using dist utils (setup.py ...
In my package root folder, I have a setup.py file see doc ... You can make use of include parameter of find_packages() :...
Read more >A Practical Guide to Using Setup.py - GoDataDriven
Just run pip install -e . again. Requirements. Most projects have some dependencies. You have most likely used a requirements.txt file before, ...
Read more >requirements.txt vs setup.py in Python - Towards Data Science
Discussing about the difference and use of requirements.txt, setup.py and setup.cfg files and how to handle package dependencies properly in Python.
Read more >How to Package Python dependencies with PIP setuptools
But for projects that consist of multiple files, need additional libraries, or need a specific version of Python, setuptools will be required.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

just imagine the future PRs and listen to your heart
@mkcor asked about this on slack, in the context of the
dash/dash-renderermonorepo that seems like it’s going in the opposite direction. Responding here to be more visible:The pieces of the
dashmonorepo will still be separate packages onPyPI- well, mostly - @byronz and I are discussing makingpytest-dashinto submoduledash.testing, butdash-rendereranddash-component-systemwill stay separate onPyPI. We’re just moving them into a single GH repo to make development easier. The reason for this is that a large fraction ofdashanddash-rendererwork is coupled, meaning two cross-referenced PRs (which are hard both to develop and to review), complicated and error-prone merge strategies, and their versions are locked anyway.Compare that to
dash-core-components,dash-html-components, anddash-table, which are staying in their own repos: we do lock versions so you only get the latest versions of these only when you upgradedash, but development tends to be mostly decoupled fromdashanddash-rendererdevelopment.If you expect there will be a lot of cross-package development between
dash-bioanddash-bio-utils, the monorepo pattern can make sense but you can still split them into two PyPI packages. If you think the development will be more or less independent in the two, the separate-repo approach that you’ve built is simpler and will be easier to maintain.