question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Setup install requirements include libraries only used in utils folder

See original GitHub issue

Related 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:closed
  • Created 5 years ago
  • Comments:10 (9 by maintainers)

github_iconTop GitHub Comments

2reactions
byronzcommented, May 24, 2019

just imagine the future PRs and listen to your heart

1reaction
alexcjohnsoncommented, May 24, 2019

@mkcor asked about this on slack, in the context of the dash/dash-renderer monorepo that seems like it’s going in the opposite direction. Responding here to be more visible:

The pieces of the dash monorepo will still be separate packages on PyPI - well, mostly - @byronz and I are discussing making pytest-dash into submodule dash.testing, but dash-renderer and dash-component-system will stay separate on PyPI. We’re just moving them into a single GH repo to make development easier. The reason for this is that a large fraction of dash and dash-renderer work 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, and dash-table, which are staying in their own repos: we do lock versions so you only get the latest versions of these only when you upgrade dash, but development tends to be mostly decoupled from dash and dash-renderer development.

If you expect there will be a lot of cross-package development between dash-bio and dash-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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found