py-gisce-client is a Python client to access the GISCE ERP

from gisce import RestApiClient as Client
url = 'http://localhost:5000'
user = 'admin'
password = 'admin'
c = Client(url, user=user, password=password)
users_obj = c.model('res.users')

from gisce import MsgPackClient as Client
url = 'http://localhost:8068'
user = 'admin'
password = 'admin'
database = 'test'
c = Client(url, database=database, user=user, password=password)
users_obj = c.model('res.users')

features = c.common.check_for_features(['my_feature'])
databases = c.db.list()
report_id = c.report('account.invoice', [1])

from gisce import XmlRpcClient as Client
url = 'http://localhost:8069'
user = 'admin'
password = 'admin'
database = 'test'
c = Client(url, database=database, user=user, password=password)
users_obj = c.model('res.users')

from gisce import XmlRpcClientWst as Client
from gisce import XmlRpcClient as Client
url = 'http://localhost:8069'
user = 'admin'
password = 'admin'
database = 'test'
c = Client(url, database=database, user=user, password=password)
c.begin() # Start a new server transaction
users_obj = c.model('res.users')
users_obj.write([1], {'name': 'Fooo'})
c.commit() # or c.rollback()
c.close()

A with_statement is supported too

with Client(url, database=database, user=user, password=password) as c:
    # All of this requests will use the same transaction
    users_obj = c.model('res.users')
    users_obj.write([1], {'name': 'Fooo'})

# on exit transaction will be rollbacked / commited if errors / no errors,
# and closed

from gisce import connect
url = 'http+xmlrpc://localhost:8069'
c = connect(url,'test', user='admin', password='agmin')
users_obj = c.model('res.users')

Where allowed protocols are:

• http[s]+restapi
• http[s]+msgpack
• http[s]+xmlrpc
• http[s]+xmlrpc-wst (XML-RPC with server transactions)

After installing the package, a pygisceclient command is available. This is useful for scripting and AI agent skills.

usage: pygisceclient [-h] --url URL --database DATABASE
                     (--token TOKEN | --user USER) [--password PASSWORD]
                     (--model MODEL | --service SERVICE) --method METHOD
                     [--service-auth {auto,raw,authenticated}]
                     [--args ARGS] [--kwargs KWARGS] [--no-verify]

Search for active users via XML-RPC:

pygisceclient \
  --url https+xmlrpc://erp.example.com \
  --database mydb \
  --user admin \
  --password secret \
  --model res.users \
  --method search \
  --args '[[["active", "=", true]]]'

Read specific fields via REST API using a token:

pygisceclient \
  --url https+restapi://erp.example.com \
  --database mydb \
  --token myapitoken \
  --model res.users \
  --method read \
  --args '[[1, 2, 3]]' \
  --kwargs '{"fields": ["name", "login"]}'

The result is printed as JSON to standard output.

Call a MsgPack service directly:

pygisceclient \
  --url https+msgpack://erp.example.com \
  --database mydb \
  --token myapitoken \
  --service common \
  --method check_for_features \
  --args '[["feature_a", "feature_b"]]'

Service calls use positional JSON arguments. By default, common, db and wc are called raw because several of their methods do not receive database, uid and password; other services are called authenticated. Use --service-auth raw or --service-auth authenticated to force one mode.

GitHub releases include a Linux x86_64 standalone CLI binary named pygisceclient-linux-x86_64, plus its .sha256 checksum. The binary is built with PyInstaller during the automated release workflow.

The release binary can be used without installing the Python package:

chmod +x pygisceclient-linux-x86_64
./pygisceclient-linux-x86_64 --help

Releases are generated from conventional commits merged into main. python-semantic-release updates setup.py, creates the release commit and tag, builds the source distribution with python setup.py sdist, and publishes the GitHub release assets. The version tag points to the release commit that contains the setup.py version bump.

The release workflow pushes the release commit and tag from GitHub Actions. If main is protected, the repository must configure GH_PAT with the required permission or branch-protection bypass for this release push. Without that bypass, the workflow will fail when pushing the version bump commit to main. The GitHub release upload includes both the dist/* source distribution and the release-assets/* standalone CLI binary plus checksum. PyPI publishing uses PYPI_TOKEN when configured, falling back to the organization-level PYPI_MASTER_TOKEN.

The release flow is:

1. A normal pull request is merged into main.
2. The release workflow runs on that merge commit.
3. python-semantic-release calculates the next version from conventional commits and existing tags.
4. The workflow updates setup.py, creates the release commit, and pushes that commit to main.
5. The workflow creates and pushes the version tag on that release commit.
6. The source distribution in dist/* and the standalone binary in release-assets/* are built from the release commit checkout.
7. The workflow creates the GitHub Release, uploads the Python distribution and binary assets to that release, and uploads dist/* to PyPI when a PyPI token is configured.