New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update conda recipe and requirements #305
Conversation
…rted): - Clean up requirements.txt file - Clean up environment.yml file - Remove conda_requirements.txt file - Update travix.yml file to use requirements.txt - Update meta.yml to use setup.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should update the instructions for installation here:
doc/contributing.rst
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure why come changes were made.
conda-recipe/rsmtool/meta.yaml
Outdated
- xlrd | ||
- xlwt | ||
|
||
- python 3.6.8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be nice to build noarch
packages that can still pin Python versions. For example, see here. Also, I don't think we want to pin to a specific version of Python 3.6. Any Python >= 3.6 should work fine, including Python 3.7 right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with everything, except I wasn't sure about 3.7. I've never tested anything with 3.7, and the old conda_requirements.txt
had python>=3.6.3,<3.7
.
conda-recipe/rsmtool/meta.yaml
Outdated
- openpyxl | ||
- xlrd | ||
- xlwt | ||
- python 3.6.8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
environment.yml
Outdated
- openpyxl | ||
- xlrd | ||
- xlwt | ||
- python=3.6.8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, let's not be too specific here.
environment.yml
Outdated
- matplotlib=2.1.2 | ||
- nose=1.3.7 | ||
- notebook=5.7.2 | ||
- numpy=1.14.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to pin numpy? Since this is only used for readthedocs, using the latest version of numpy should be fine right? And same for pandas
etc.?
requirements.txt
Outdated
@@ -4,18 +4,17 @@ joblib==0.11 | |||
matplotlib==2.1.2 | |||
nose==1.3.7 | |||
notebook==5.7.2 | |||
numpy==1.14.* | |||
numpy==1.14.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong feelings about this, but I'm always paranoid about differences in even minor version of numpy
leading to small differences in results.
@@ -4,18 +4,17 @@ joblib==0.11 | |||
matplotlib==2.1.2 | |||
nose==1.3.7 | |||
notebook==5.7.2 | |||
numpy==1.14.* | |||
numpy==1.14.0 | |||
pandas==0.23.4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do things break if we use the latest version of pandas
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. I'll test it out. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me. I would probably concur with Nitin on not pinning to too specific versions to avoid conflicts with other tools since most of the computations we do are not too complex.
@jbiggsets what's the status of this PR? |
Looks like I have a few minor comments to address still. I'll let you know when it's ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more minor change.
conda-recipe/rsmtool/meta.yaml
Outdated
@@ -9,7 +11,7 @@ build: | |||
number: 0 | |||
script: | |||
- cd $SRC_DIR | |||
- $PYTHON setup.py install | |||
- $PYTHON setup.py install --single-version-externally-managed --record=record.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you don't need to do this since its use is discouraged. See the SKLL recipe for a much easier alternative.
We should also check that we aren't bundling test data (which tends to be large) into our conda or PyPI package. |
Why would that be the case, and how would we check that? |
In SKLL, when I just did |
The installation instructions will be updated in an upcoming PR.
The conda package was tested and worked fine on both Linux and Windows as seen here. Therefore, I am now merging this PR. |
…ingService/update-conda-recipe Update conda recipe and requirements
This PR is intended to address #297, but it includes several additional changes that should to be reviewed closely.
Here is a quick rundown of the changes:
Removed
conda_requirements.txt
. Previously, we were maintaining two sets of requirements:requirements.txt
andconda_requirements.txt
. The second was being used to createconda
environments (usingconda create -n foo --file conda_requirements.txt
). However, since these sets of requirements were virtually identical and both can be used to createconda
environments, I discarded theconda_requirements.txt
file. The one major difference between these files is thatconda_requirements.txt
hadzeromq
. This cannot be in therequirements.txt
file, since it leads to an error when usingpip install -e .
. I think this is all right, since it's not entirely necessary (and may be installed byJupyter
anyway?), but we can add it to themeta.yaml
separately, if it's a problem. (See below on the updates tometa.yaml
.)Switched to
requirements.txt
in.travis.yml
. Related to the above, ourtravis.yml
file had previously usedconda_requirements.txt
to set up theconda
environment for our builds. This has been changed to userequirements.txt
in our Travis build.Updated
requirements.txt
. Some minor tweaks were also made to therequirements.txt
file, mostly reordering the list of requirements. I also removedscikit-learn
(since this is already askll
dependency).Updated
meta.yaml
to usesetup.py
. Previously, themeta.yaml
file was listing all of the requirements manually, which meant we had to ensure these requirements were always up-to-date. I changed this configuration file to instead rely on thesetup.py
data, and pull the requirements directly frominstall_requires
. This update takes advantage ofJinja
templating. I tested this on my Mac, and it worked. I am going to test it on a Windows machine today, and it would probably be good to have others test it on their machines, as well.Re-generated
environment.yml
. Finally, I re-generated theenvironment.yml
to ensure that it was consistent with ourrequirements.txt
file.Add missing test file. Added
test_container.py
to.travis.yml
and Azure, pertest_container.py
missing in both.travis.yml
andazure-pipelines.yml
#310.