Open
Description
There are a number of ideas in pull request #115 that won't make it into the 2.0.6 release, so I'm gathering them here for future consideration.
First, unaddressed goals from the start of that pull request:
- simplify dependencies
- group optional dependencies into one additional set? (
conda install switch_model_extras
/pip install switch_model[extras]
) - require users to explicitly install some specialized dependencies ad hoc? (rpy2 and numpy for iterative demand response, psycopg2-binary or eventually google-cloud-bigquery for accessing the Hawaii back-end database)
- should we include testing-oriented packages (pint, maybe testfixtures?) in extras, or just list them as something to add ad hoc if running tests? (may be moot if we can figure out a way to get our tests to run without needing pint, which pyomo needs during testing but does not include in the distribution)
- group optional dependencies into one additional set? (
- streamline installation instructions
- recommend this sequence for most users?
conda install -c defaults -c conda-forge switch_model
orpip install switch_model
(+find glpk somewhere) for most users?
- these users can look at the source code on github or in their system install directory if needed, which is how I interact with Pyomo
- in my experience long-term dependcy problems are reduced by making conda-forge the top-priority channel (
conda config --add channels new_channel
). Should we recommend this for all users, or would that be too much meddling in people's system configuration?
- recommend this sequence only for people who want to edit the source code and contribute back?
git clone https://github.com/switch-model/switch.git && cd switch
- if running anaconda:
conda install --only-deps switch_model
pip install --editable .
orpython setup.py develop
(note:conda develop
doesn't install command-line scripts or dependencies; see how to use conda develop? conda/conda-build#1992 (comment))
- recommend this sequence for most users?
- maybe add some commands to give easier access to source code hidden in a site-packages directory:
switch find <module>
: report file path to specified module (possibly just a submodule within switch_model)- then users can view or edit source code via commands like
atom `switch find switch_model`
,mate `switch find pyomo`
or maybeatom `switch find discrete_commit`
.
- then users can view or edit source code via commands like
switch install examples
: copy examples directory to local directoryswitch solve --trace [[<module>|<file>[:<function>|<line>]], [<module>[:<function>]], ...]
: invoke the debugger (a) when particular callbacks are called, (b) when any callback in the specified module is called (if no function specified), or (c) whenever any callback is called (if no modules specified).- This could be implemented either via tests when we call callbacks, or by creating tracing wrappers for the specified callbacks, or by subclassing Pdb and setting breakpoints in the right places (that is nice and general but may run slower and ties us to Pdb?)
Metadata
Metadata
Assignees
Labels
No labels