WIP: Version 1.5.1, and split into geoviews-core + geoviews #4
Conversation
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
@conda-forge-admin, please rerender |
|
Hi! This is the friendly automated conda-forge-webservice. I rerendered the feedstock and it seems to be already up-to-date. |
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
ceball
changed the title
recipe/meta.yaml
Outdated
|
|
||
| package: | ||
| name: geoviews | ||
| name: {{ name }} |
There was a problem hiding this comment.
Defining a variable that will be used only once is adding a line and obfuscating the recipe for no real gain. Do you mind reverting this change?
There was a problem hiding this comment.
I have no problem reverting this.
(I copied it from conda-forge's docs at https://github.com/conda-forge/staged-recipes/blob/master/recipes/example/meta.yaml, but I guess there name is also used in the download link.)
There was a problem hiding this comment.
Yeah, that makes sense only when copying and pasting to create a new recipe, which we don't do anymore thanks to conda-skeleton. It is a relic that only obfuscate the recipe.
| - bokeh >=0.12.15 | ||
| - libgdal | ||
| - matplotlib | ||
| - netcdf4 <1.4.0 |
There was a problem hiding this comment.
This is requiring a lot of extras! Indeed a core package is needed for this case.
Are you planning on using split packages and a single recipe?
There was a problem hiding this comment.
I'm not planning to do anything different from what I've already done here and at conda-forge/staged-recipes#6042 (i.e. geoviews is a metapackage that depends on geoviews-core, and the recipes are separate(*)). However, I'm totally open to suggestions about how to do it better (especially if you can link to an example I can copy...).
(I should point out I'm not an author or maintainer of geoviews; any opinions I express are my own :) )
(*) we release (dev) packages to the pyviz (dev) channel; those recipes are templated to avoid duplication of metadata, which also ensures the version of geoviews and geoviews-core matches.
|
@ocefpaf, do you know what to do about the license in this case (i.e. for a metapackage containing no source code)? (My guess would be to remove |
|
We should add a license manually. See https://conda-forge.org/docs/meta.html#packaging-the-license-manually |
|
The license will be included by geoviews-core, though...I guess I'm wondering what there is to license in the metapackage? (Still, happy to follow the suggestion.) |
|
I get that it is redundant but every package needs a license, even a metapackage 😬 |
|
|
||
| about: | ||
| home: http://geoviews.org | ||
| license: BSD 3-Clause | ||
| # license_file: LICENSE # license is not packages in the source tarball :-( | ||
| summary: 'GeoViews is a Python library that makes it easy to explore and visualize geographical' | ||
| license_file: '{{ environ["RECIPE_DIR"] }}/LICENSE' |
There was a problem hiding this comment.
oops! missed it from my commit
Checklist
0(if the version changed)conda-smithyHave split geoviews into geoviews and geoviews-core, so that there's a useful package for users, and a version more suitable as a dependency for "application developers". Depends on: conda-forge/staged-recipes#6042
Note: I'm not sure about the netcdf version specification. We have it described in the master list of dependencies as "currently needed for libgdal on defaults (but not c-f)". However, since that was written, I don't know how things might have changed. I propose to remove the pin and see what happens.
So, also to do: