Skip to content

check in linter for required python run-time dependency#547

Closed
kain88-de wants to merge 2 commits intoconda-forge:masterfrom
kain88-de:linter-python-dep
Closed

check in linter for required python run-time dependency#547
kain88-de wants to merge 2 commits intoconda-forge:masterfrom
kain88-de:linter-python-dep

Conversation

@kain88-de
Copy link
Copy Markdown
Contributor

This will ensure that conda is forced to add a python version dependency on the
final package.

I encountered this problem for the MDAnalysis feedstock.
conda-forge/mdanalysis-feedstock#4

I haven't tested this locally yet because I don't know if I can go back to my a stable build or even run the tests without installing the development version.

@kain88-de kain88-de force-pushed the linter-python-dep branch 2 times, most recently from bfc1b5d to 0a88029 Compare July 17, 2017 11:53
@kain88-de
Copy link
Copy Markdown
Contributor Author

test pass now on travis

This will ensure that conda is forced to add a python version dependency on the
final package.
@kain88-de kain88-de force-pushed the linter-python-dep branch from 0a88029 to f887419 Compare July 17, 2017 12:02
Comment thread conda_smithy/lint_recipe.py Outdated
for selector_line in selector_lines(fh):
if 'py3k' in selector_line and 'python' not in requirements_section.get('run', ''):
lints.append("When building python 2 only packages include python as a run-time "
"dependency to ensure it can't be installed on python 3.")
Copy link
Copy Markdown
Member

@isuruf isuruf Jul 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some packages that needs python as a build dependency, but does not require python. I use one python because I don't need a matrix of builds. In that case, according to this, it's a lint failure

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only ensures a requirement for Python if the package is Python 2 only. could you give an example problem where this would be a problem.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, I have a package with a build script written in python 2. So, I skip py3k, but the package itself doesn't need python in run.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe have this just for packages from pypi?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kain88-de that assumption is blurred with wheels and we have tons of package that are python but not hosted at PyPI making this solution "flaky." So using the source URL to determined that is not reliable.

TL;DR unless we add an extra metadata to indicate that the recipe is pertinent to a python package we cannot do this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK then I'll drop this in this PR. But I have another question could we have 2 warning types in the linter. The first would be errors that we have now. The second type would be suggestions/hints to help packagers.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe namespaces could be leveraged depending on if/when/how they are constructed.

Copy link
Copy Markdown
Member

@jakirkham jakirkham Jul 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second type would be suggestions/hints to help packagers.

Indeed. This sort of idea has come up before ( #317 ). Some warnings like, "this might need python", could be a reasonable compromise IMHO.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK then I'll drop this in this PR. But I have another question could we have 2 warning types in the linter. The first would be errors that we have now. The second type would be suggestions/hints to help packagers.

Indeed warning type linting is something we should do!

Comment thread conda_smithy/lint_recipe.py Outdated
# 13: If cython is a build-dependency then python should be a run-time
# dependency. This ensures that packages will be marked correctly by conda
if 'cython' in requirements_section.get('build', '') and 'python' not in requirements_section.get('run', ''):
lints.append("When using cython then python should be a run-time dependency")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems very specific. There are number of errors like this, but we can't add all of them. (swig, numpy as build dependency.)

How about something more generic like if python is an implicit runtime requirement, then it should be added explicitly in runtime requirements?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you detect an implicit requirement?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extending this also to numpy/swig/etc isn't hard

Comment thread conda_smithy/lint_recipe.py Outdated

# 13: If cython is a build-dependency then python should be a run-time
# dependency. This ensures that packages will be marked correctly by conda
build_deps = ['cython', 'numpy x.x', 'swig']
Copy link
Copy Markdown
Contributor Author

@kain88-de kain88-de Jul 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there also be a check that numpy is specified as numpy x.x when it appears in the build requirements?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

swig can be used for lots of things (not just python). Would rather not require people have python with swig.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed swig from that list. Should I add the numpy x.x check?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO that seems ok.

@kain88-de kain88-de force-pushed the linter-python-dep branch 4 times, most recently from e218798 to 6a02663 Compare July 21, 2017 08:16
Comment thread conda_smithy/lint_recipe.py Outdated
lints.append("Found python related compilation requirement "
"please add python as a run-time dependency")

# 14: If numpy is in build requirements ensure it's stated as `numpy x.x`
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here is the additional check for numpy x.x in the build requirements. The tests pass now again.

- implicit python dependency when building with cython/numpy
@kain88-de kain88-de force-pushed the linter-python-dep branch from 6a02663 to 9dc2e7b Compare July 21, 2017 16:26
@kain88-de
Copy link
Copy Markdown
Contributor Author

I removed the numpy check again. With conda-forge/conda-forge.github.io#415 it changed anyway how to setup numpy

@kain88-de
Copy link
Copy Markdown
Contributor Author

Is there still any interest in this?

@kain88-de
Copy link
Copy Markdown
Contributor Author

@ocefpaf still interested in lint check?

@ocefpaf
Copy link
Copy Markdown
Member

ocefpaf commented Aug 9, 2017

We are moving away from the numpy x.x syntax, so I guess that this PR may be DOA.

I'll leave the decision to you and the conda-smithy authors.

@kain88-de
Copy link
Copy Markdown
Contributor Author

Is there still interest in this? I think updating this to the new default of building against old numpy versions shouldn’t be to difficult.

@kain88-de
Copy link
Copy Markdown
Contributor Author

Is this still interesting or can the PR be closed?

@kain88-de kain88-de closed this May 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants