Google Earth Engine API: the Python and JavaScript clients

Two client libraries and one hosted backend

The repository description is short and worth quoting in full, because it settles a confusion that catches almost everyone new to Earth Engine: this is Python and JavaScript bindings for calling the API. What lives here is the client code you install or open in a browser, not the imagery catalogue, not the model code, not the machines that evaluate a filter across a continent. That division explains several practical details. It explains why the language field reads JavaScript even though the Python package is the half more people install from a shell. It explains why Python installation is handled by a separate page on the documentation site rather than by a command printed in this README. And it explains the shape of the three links at the top of the file, which point at the Earth Engine homepage, the web Code Editor, and that Python installation page rather than at anything you could clone and run on your own machine. Questions about where the data sits, how a query is billed, or which server does the work are questions for the hosted service. Questions about how to express a query, how to authenticate, and how to get results back into your session are answered here.

Following the night-time lights example from helper to collection

The README pairs a screenshot with a Code Editor snippet, and the snippet is worth reading closely because it shows the shape of nearly every Earth Engine script you will write. A helper function takes an image and returns a new one with an added band holding the acquisition date, expressed as years since 1991:

// Adds a band containing image date as years since 1991.
function createTimeBand(img) {
  var year = ee.Date(img.get('system:time_start')).get('year').subtract(1991);
  return ee.Image(year).byte().addBands(img);
}

Subtracting a fixed epoch year is the trick worth copying. Rather than handling dates in a separate parallel structure, the script turns each date into a numeric band that travels with the image everywhere else in the pipeline, where reducers can use it as an independent variable. The next part builds the collection and maps the helper over it:

var collection = ee.ImageCollection('NOAA/DMSP-OLS/NIGHTTIME_LIGHTS')
    .select('stable_lights')
    .map(createTimeBand);

Two details stand out. The collection is constructed from a dataset identifier string rather than a file path, because the pixels come from Google's catalogue. And the band selection happens before the mapping, which keeps the request small: the underlying dataset carries considerably more than the single measurement this analysis needs, and narrowing first is cheaper than filtering after.

One reducer, three bands and an unusual legend

The closing part of the example collapses the entire time series into a single image, then hands it to the map with an explicit visualisation range:

Map.addLayer(
    collection.reduce(ee.Reducer.linearFit()),
    {min: 0, max: [0.18, 20, -0.18], bands: ['scale', 'offset', 'scale']},
    'stable lights trend');

That dictionary is unusual enough to deserve a pause. The minimum is a plain number while the maximum is an array of three values, and the band names list scale, offset, and scale a second time. The repetition looks like a typo but it is not one: the linear fit reducer produces a slope with separate positive and negative components, and those two components share the name scale because they are the same quantity measured in two directions. The offset channel carries the intercept, the fitted value at the epoch year, which serves as a workable stand-in for baseline brightness. Splitting the slopes into separate channels means a region that is growing and a region that is fading can be read as different colours instead of cancelling into an average that describes nothing in particular.

Bug reports do not go to GitHub Issues

Under a NOTICE heading the README says the project is using the Google Issue Tracker rather than the GitHub issue tracker, so that bug reports and feature requests reach a team that can act on them, and it points at the Get Help page of the Earth Engine documentation for details on browsing and submitting issues there. This is worth knowing before you file anything, because a GitHub issue opened against this repository is not the channel its maintainers are watching. The metadata lists 22 open issues, which is a small number for a library with this much usage and much easier to explain once you know where the queue actually lives. The same notice is a hint about the shape of the project: this code is developed alongside a hosted platform, and the two support systems are kept separate even though the code is open.

What three releases reveal about maintenance

The release history is short and mostly informative once you read it as a maintenance record rather than a feature list. Two of the three entries are release candidates. The newest, v1.7.46rc0 published on 2026-09-22, has an empty body, so it tells you a candidate exists and nothing about what changed inside it. The substantive entry is v1.7.45 from 2026-09-21, and its four bullets are mostly signals about the client libraries themselves. Build artifacts were refreshed for v1.7.45rc0. A Pyrefly upgrade to version 1.2.0 was preceded by suppressing new findings, which tells you the project runs a Python type checker in CI and had accumulated enough fresh complaints to hold the upgrade back. Dependency minimums in pyproject.toml were raised, the kind of change that quietly breaks environments pinned to older transitive versions. And ee.Filter.and plus ee.Filter.or now accept an ee.List, which is a genuine interface change: filters that previously took a fixed number of arguments can now be built from a list whose length you decide at runtime. The closing note is worth reading on its own, since it says the changelog covers client libraries only and that backend service changes and notifications live in the Earth Engine release notes on the documentation site.

A small tree, and what the numbers imply

The repository tree is flat and short: a README, a LICENSE, a CONTRIBUTING file, a .github directory, then javascript, python and demos as the three substantive folders, plus trendy-lights.png at the root, which is the screenshot the README uses to illustrate its own example. The presence of both language directories under one repository is the clearest on-disk evidence for the two-client picture described at the start, and the demos folder suggests the examples live here rather than being scattered across documentation pages. The metadata lists Apache-2.0 as the license, JavaScript as the primary language, 3,427 stars and 1,097 forks. The fork count is worth reading as a signal rather than a decoration, because for a client library forks often track people who need to patch something locally or hold a specific version in place. The default branch is named master, the repository is not archived, and the last push was on 2026-09-23, which together say the client libraries are still being shipped against a moving backend.

Editorial conclusion

The concrete next step is small. Install the Python package, authenticate against a cloud project, and port the night-time lights snippet into a script of your own, because it exercises the helper pattern, the collection construction and the reducer display path in under twenty lines and gives you a working baseline before you touch a real analysis. If you need the interactive path, open the Code Editor the README links to and run the same code there, then compare what the two clients return for the same dataset identifier.

Frequently asked questions

Official sources

1. google/earthengine-api on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases