Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Build a wheel binary distribution that includes ecCodes #1

Open
alexamici opened this issue Feb 2, 2019 · 4 comments
Open

Build a wheel binary distribution that includes ecCodes #1

alexamici opened this issue Feb 2, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@alexamici
Copy link
Contributor

alexamici commented Feb 2, 2019 •
edited
Loading

At the moment ecCodes must be installed on the system for eccodes-python to work.

Following thew strategy of https://github.com/mapbox/rasterio it would e possible to package the whole ecCodes library and data files in the multilinux wheel binary package.

Pro:

  • no need to have two install steps, only pip install eccodes-python
  • no need to install ecCodes as root

Con:

  • huge binary wheel package
  • possible conflicts with other Python packages that link to ecCodes (quite remote)

The infrastructure used by rasterio is here: https://github.com/sgillies/frs-wheel-builds

Was: ecmwf/cfgrib#22
@alexamici alexamici mentioned this issue Feb 2, 2019
Closed
@datarods-svc
Copy link

It would be good if cfgrib just uses eccodes-python. For now, python -m cfgrib selfcheckstill fails with eccodes-python. Thanks.

@dtip
Copy link
Contributor

dtip commented Dec 5, 2019

@alexamici I can see that cfgrib is on conda-forge and uses the ecCodes package from there.

Does that mean this issue is resolved? conda install -c conda-forge cfgrib gives the one-line install step you want and manages deps for you.

@alexamici
Copy link
Contributor Author

@datarods-svc migrating cfgrib on eccodes-python is tracked here: ecmwf/cfgrib#95 the main blocker is the conda package with eccodes-python

@dtip [note that I updated the issue description with eccodes-python not cfgrib] the issue is now much lower priority thanks to the conda packages, but that it would still be nice to have a multilinux wheel for users who are not on conda.

@alexamici alexamici added the enhancement New feature or request label Dec 5, 2019
@dtip
Copy link
Contributor

dtip commented Dec 5, 2019

I see - thanks for clarifying

FussyDuck pushed a commit that referenced this issue Jun 23, 2022
@oiffrig @shahramn
Pull request #1: ECC-1415 Add a high-level interface
145976e 
Merge in ECCODES/eccodes-python from feature/highlevel to develop

* commit '142b2a19caa9ebe77d776aab20eccf15c22c1b9c': (29 commits)
  Allow requesting the keys as "name:type"
  Add more unit tests
  Add GRIBMessage.data
  Handle missing values as non-existent
  Rename Message.get_data to get_data_points
  Add tests for the high-level interface
  Black formatting and isort
  Add dict-like interface to Message
  Translate eccodes.KeyNotFoundError to KeyError
  Run flake8 (v3.9.2)
  Run isort (sort imports)
  Black formatting
  Support getting alternative key representations
  Split out GRIB-specific features into GRIBMessage
  Rename Message.handle to Message._handle
  Add Message.dump()
  Support arrays in Message.get
  Make Message.__del__ immune to teardown errors
  Add Message.__copy__
  Expose high-level interface classes in the eccodes package
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alexamici @dtip @datarods-svc