Good First Issues in Python

Add examples related to geospatial data in lumen

On the organiser Sessions overview, several columns can already be sorted, but the Speakers column cannot. Organisers should also be able to sort sessions according to the assigned speaker(s). Expected behavior Make the Speakers column sortable. Support ascending and descending sorting. Sort alphabetically by speaker name. For sessions with multiple speakers, use a consistent rule, e.g. the first listed speaker. Sessions without a speaker should be grouped consistently at the beginning or end. Use the same sorting icons and behavior as the other sortable columns. Acceptance criteria Clicking Speakers sorts sessions alphabetically by speaker. Clicking again reverses the order. Multi-speaker sessions sort consistently. Sorting works together with the existing search and filters. The active sort direction is visibly indicated.

The organiser overview tables under Rooms, Tracks, Types should support sorting by the columns available on each page. This should follow the same sortable-table behavior already used elsewhere in Eventyay. Expected behavior Add ascending/descending sorting to all meaningful columns on: Rooms Name Capacity Tracks Track Color Proposals Session Types Sort by the columns shown on that page, excluding action/control columns Do not make the final Actions column sortable. Acceptance criteria Column headers show the standard Eventyay sorting indicator. Clicking a sortable column toggles ascending/descending order. The active sort column and direction are clearly indicated. Sorting works together with any existing filters/search. Actions/reorder controls remain unaffected. The implementation is consistent across Rooms, Tracks, and Session Types.

The organiser Speakers overview should allow organisers to sort the speaker table by the most relevant columns. Currently the table does not provide sorting for these values. Expected behavior Enable ascending/descending sorting for: Name Accepted Proposals Proposals Arrived / Not arrived Use the same sortable-column behavior and icons already used in other Eventyay tables. For the arrival column, sorting should group speakers by their arrival status, e.g. Arrived and Not arrived. Acceptance criteria All four columns can be sorted ascending and descending. The active sort column and direction are visually indicated. Sorting works together with existing search and filters. The selected sorting is preserved while filtering/paging where applicable. The implementation follows the existing Eventyay table sorting pattern.

Problem Description Currently, the email.bulk.monthly (Monthly Bulk Emails) capability limit defined in eventyay-business is only enforced and recorded for emails dispatched via the Talks / CFP mailer (app/eventyay/orga/views/mails.py). In the Tickets / Orders area (app/eventyay/plugins/sendmail/), organizers can also compose and dispatch bulk emails to attendees/orders. However: There is no call to check_entitlement(organizer, 'email.bulk.monthly', quantity=recipients_count) before queuing or scheduling emails in sendmail/views.py. When bulk emails are dispatched via send_queued_mail in sendmail/tasks.py, no entitlement_usage_recorded signal is dispatched to deduct the quota from the organizer's monthly limit. As a result, bulk emails sent through the Tickets section bypass plan allowances and can be sent without limit. Expected Behavior Entitlement Check on Composition & Queueing: Before an email is added to the outbox or scheduled in app/eventyay/plugins/sendmail/views.py, calc

Description soup train --cloud modal|lambda leaves train() at the end of its if cloud: block (src/soup_cli/commands/train.py:1046, exits at :1112 for --cloud-submit and :1117 for plan-only). The remote run is built from the config text plus --gpu and nothing else: the Modal stub runs ["soup", "train", "--config", _CONFIG_PATH, "--yes"] (cloud/modal.py:180) and the Lambda cloud-init runs soup train --config soup.yaml --yes (cloud/lambda_labs.py:117). No other argv, and no environment variable, secret or env= reaches the remote machine. Every option of train that is read only below line 1117 is therefore accepted, never read, and never mentioned. The command prints the normal plan panel and exits 0. 22 options (line numbers on main, before #1584; signature line, then where the flag is first read): Flag Signature Read at What the user loses --dry-run 540 1397, 1557, 1710, 1722 --cloud-submit --dry-run submits the run: submit_*_run never looks at it --resume / -r 545 1164 (:938 is

#1526 adds an inbox for inter-agent messages to the Claude Code hooks. This issue adds the same inbox to the OpenCode plugin, so agents in a mixed Claude Code / OpenCode cluster read messages the same way. The background is in #1526 and in docs/agents/README.md, section "Tags as inter-agent signals". In short: one agent stores a memory carrying a sentinel tag such as msg:cluster (with X-Agent-ID, the author shows up as an agent:<id> tag), and the others pick up everything with that tag since they last looked. Where it fits in the plugin opencode/memory-plugin.js already has the pieces: experimental.chat.system.transform runs on every system prompt and already pushes formatted memories into output.system. The inbox block goes there too. The plugin is a long-lived process. Unlike the Claude Code hooks, it can keep the last check time and a per-session state in memory (sessionState), so throttling needs no file on every call. client.tui.showToast and writeStatus, which feeds the sidebar

docs/agents/README.md (section "Tags as inter-agent signals") documents a pattern that people already run: agents use one memory service as a message bus. One agent stores a memory with a sentinel tag such as msg:cluster (its author shows up as an agent:<id> tag when it writes with X-Agent-ID), and another agent filters on that tag. A five-agent cluster does its cross-agent communication this way. The reading side is entirely manual. Nothing polls on a schedule, nothing remembers what was already seen, and nothing puts the messages in front of an agent. With the self-hosted sync hub and delta-sync in v12, more setups share one store across machines, so this gap matters more. Why this goes in the hooks, not the server The server can already find the messages. What it can't do is put them into an agent's context. A scheduled job in the HTTP server would find messages and have nowhere to deliver them. The Claude Code hooks are where the agent's context is assembled, and they already query

The landing page at mcpmemory.services got a new design in #1508 to #1511. The dashboard (src/mcp_memory_service/web/static/) still uses the old Tailwind-style palette and system fonts, so the two look like different products. This issue brings the dashboard's design tokens in line with the site. It is a token swap, not a redesign. The brand, as the site defines it Everything below is in site/assets/site.css and site/assets/fonts/. Colors (light) Token Value Role --paper #eef3f6 page background --panel #ffffff cards, surfaces --ink #0c1626 body text, headings --muted #4f5f72 secondary text --line #d3dde5 borders, dividers --cyan #19c2da accent: primary actions, highlights, focus --cyan-soft rgba(25,194,218,.16) accent backgrounds --blue #0a86b8 accent on light backgrounds (links, kicker text) --band #0d1a2c navy header band --band-text / --band-muted #e9f2f7 / #92a6b8 text on the band --console #08111d code and terminal blocks Colors (dark), from the site'

What happened? RandomMosaic(padding_mode=...) accepts any string. The argument is read only with cropping_mode="resample"; with the default cropping_mode="slice" it is ignored, so a misspelt value such as "zero" or "bogus" passes silently. With cropping_mode="resample", the same value is not checked at construction either, and the first forward call fails inside torch.nn.functional.grid_sample with torch's message. The docstring says "Should be: constant, reflect, replicate." and does not say the argument only matters for cropping_mode="resample". Minimal reproduction import torch import kornia.augmentation as K x = torch.rand(2, 3, 32, 48) for cropping_mode in ("slice", "resample"): for padding_mode in ("constant", "bogus"): try: torch.manual_seed(1) K.RandomMosaic((32, 48), p=1.0, padding_mode=padding_mode, cropping_mode=cropping_mode)(x) print(cropping_mode, padding_mode, "ok") except ValueError as e: print(croppi

Description Invalid eval-gate suite YAML does not consistently reach the existing usage-error boundary. On main ab0b952090b268f795095752789decf46c191745, a truthy sequence or scalar root reaches EvalSuite(**data) and raises TypeError; malformed YAML raises yaml.parser.ParserError during safe_load. The CLI catches FileNotFoundError and ValueError only, so these inputs exit 1 without the Cannot load suite: diagnostic rather than the documented usage exit 3. This is a loader error-normalization defect, not an empty-task verdict or a non-finite baseline problem. No PASS/FAIL verdict or model construction occurs in these reproductions. Steps to reproduce Use each of these as bad-suite.yaml, then run soup eval gate --suite bad-suite.yaml: - suite: bad-root tasks: [] true suite: [ The first two produce a TypeError from the loader. The third produces a ParserError. The observed CLI exit is 1 in both no-model and --model synthetic-model cases. By contrast, a mapping with a missing required su

Description Hygiene follow-up to #1758 / #1776. Re-verified against origin/main a83218311 (the #1776 merge commit): _fail, the import at line 85 and line 129 are as cited. _fail in src/soup_cli/commands/ship.py (lines 127-130) prints escape(message) (line 129). That neutralises Rich markup but does not strip control bytes, so a raw ESC (0x1B) in the message reaches the terminal. #1776 adds ValueError("cannot render chat template with chat_template_kwargs: {exc}") in utils/live_eval.py, and _verdict_live forwards it as _fail(f"live ship verdict failed: {type(exc).__name__}: {exc}", ...) (in _verdict_live). That {exc} is raised while rendering a chat template shipped with a Hub model, so it is text the user did not write and should get the same terminal hygiene as the rest of the CLI output. Note for whoever picks this up: the for_terminal already imported at ship.py:85 is NOT utils/terminal.py:for_terminal. It comes from utils/ship_verdict.py:54 (from soup_cli.utils.terminal import stri

The pixtral-dpo recipe (src/soup_cli/recipes/catalog.py:2676, added 2026-05-31) declares task: dpo, modality: vision, data.format: llava, image_dir, train file vision_preference_train.jsonl, and is described as "multimodal preference alignment". Checked on main 1788467, trl 0.29.1, CPU, CUDA_VISIBLE_DEVICES=-1. Config load accepts it: load_config_from_string(RECIPES['pixtral-dpo'].yaml_str) is valid (dpo / vision / llava). The only vision+dpo validator, _validate_dpo_vision_backend (schema.py:6875), checks the backend only, and tests/test_issue1099_moe_lora_remaining_tasks.py:477 pins dpo + llava as a config that loads. Data: llava rows (image + conversations) convert to {messages, image} (_convert_vision, data/formats.py:533). soup data validate rows.jsonl --format llava prints "3/3 rows valid", exit 0. soup train --config recipe.yaml --dry-run prints "Data OK ... Config valid. Ready to train!", exit 0. Trainer: DPOTrainerWrapper.setup (trainer/dpo.py:157, :228) passes those rows to

Description Follow-up to #1773 / #1779 (test first). Verified against origin/main 2d45dea66 (the #1779 merge). #1779 refuses NaN/inf baseline scores with ValueError, but an integer too large for a float (10**400, or -10**400) raises OverflowError before any finite check, and OverflowError is not a ValueError, so the callers that turn a bad baseline into a usage error miss it. Sites in src/soup_cli/eval/gate.py: _coerce_score_map line 213, fval = float(value): the read path for flat and stamped baseline files (resolve_baseline, calls at lines 397 and 406; the registry call at 345 only sees floats from SQLite). stamp_baseline_scores line 168, fval = float(value) (also reached by write_baseline_file, which calls it at line 194, so no file is created). run_gate line 606, math.isfinite(base_val) on the raw value: math.isfinite(10**400) raises the same OverflowError. The later delta = score - base_score at line 647 would raise it too, but is not reached today. Callers that catch only Value

Description Follow-up to #1596 / #1602 (CLI hygiene; start after #1602 merges). #1602 routes replies, prompts and keys through utils/terminal.py:for_terminal, but the model/output PATH strings printed next to them are still raw Rich markup. A path like models/[/x] raises MarkupError, run-[red]7 prints as run-7, and control bytes pass through. Re-verified against origin/main c6d48e3c7 (the #1602 merge commit): every site below is still a raw f-string. Sites still raw on main (src/soup_cli/commands/...): chat.py: 89 (Model path not found), 114 (Model: line of the "Loading model" panel), 243 and 246 (Loading LoRA adapter / model: {model_path}). The base_model lines 115 and 236 already use for_terminal. diff.py: 88 and 91 (Model A / B not found), 184 (Results saved to {out_path}), 246 (Cannot detect base model for {path}). The "Diff Plan" panel (108-109) is done by #1602. eval.py: 92 (benchmark) and 374 (custom) Model path not found; in human: 949 (Model not found), 955-956 (Model A: / Mo

Description Follow-up to #797 / #1778 (start after #1778 merges; a small, mechanical change that suits a first contribution). #1778 makes the grpo, ipo, bco, reward_model and online_dpo trainers pass training.gradient_checkpointing to TRL. With the key unset they now follow the schema default false (config/schema.py:3120-3123), where TRL's own config default was true (checked on trl 0.29.1, the pyproject floor: GRPOConfig, DPOConfig (used by ipo), RewardConfig, trl.experimental BCOConfig and OnlineDPOConfig all default True). So shipped configs that leave the key unset silently use more activation memory. pretrain and embedding are unaffected (HF default is False). Re-verified against origin/main 5d57c1f2a (the #1778 merge commit): same 30 entries, same lines. Evidence Counted by parsing every shipped config on main: 30 leave the key unset (expected 25 = items 1+2; items 3+4 are extra), 11 grpo recipes already set true. src/soup_cli/recipes/catalog.py, 22 recipes ("name": RecipeMeta(

soup data review "nope[/]x.jsonl" (file missing) exits 1 with Error: MarkupError: closing tag '[/]' at position 28 has nothing to close instead of "File not found". Same on data validate x.jsonl --format "x[/]y", data convert ... --to "x[/]y", data unregister "x[/]y", data ingest "nope[/]x.pdf", data from-traces --logs "nope[/]x" --format openai. nope[bold]x.jsonl does not crash but prints File not found: nopex.jsonl (the tag is swallowed, wrong name shown). Root cause: user text is interpolated into console.print markup unescaped, e.g. src/soup_cli/commands/data.py:2268 ([red]File not found:[/] {input_file}), 40/43 (inspect), 2085/2088 (--logs), 2929-2942 (ingest file), 109/123/139 (--format), 179/194 (--to), 2002/2004 (unregister). On Windows, Path-typed variables hide the [/] crash (Path turns it into [\]); on Linux/macOS data inspect "nope[/]x.jsonl" crashes too (verified with PurePosixPath), so CI on Linux is the platform that sees it. Same shape, not yet exercised: path variables

Description The v0.18.0 GitHub release exists, but its server and host container images are missing from GitHub Container Registry. This blocks Docker/Compose users and registry-based update tools from upgrading to the release. The release's Publish images (public) run was cancelled during the first image build. The build-and-push job ran from 07:21:34 to 09:22:42 UTC on 2026-10-13. The tagged workflow sets timeout-minutes: 120; the duration and cancellation are consistent with that limit being reached. The last active work in the log was the emulated linux/arm64 build, around the Python editable installation and web build. I did not find a definitive dependency/compiler error explaining why progress stopped, so the underlying build slowdown or stall still needs investigation. Steps to reproduce Inspect these public manifests: docker buildx imagetools inspect ghcr.io/omnigent-ai/omnigent-server:v0.18.0 docker buildx imagetools inspect ghcr.io/omnigent-ai/omnigent-host:v0.18.0 Both tags

Seen in the real test for #341. An MCP send_email call ("mcp_mailer: Send an email to one address") was shown with the heading "Sentient wants to post something publicly" and a "Posts publicly" badge. The card's heading seems to be guessed from words in the tool's arguments or description, and the email body contained text that looked like a post. Fix: decide the heading from the tool's name and declared risk first (send_email, gmail_send... means "send an email"), and use word guessing only as a last resort, never from the arguments' content. Add tests for an email whose body says "post", "publish" or "tweet". Done when: that call shows "Sentient wants to send an email", checked in the built app.

Description antigravity-native launches agy with a per-session isolated --gemini_dir=<bridge>/agy-home/.gemini. agy reads the user's global rules from that Gemini dir, but seed_isolated_agy_home() never seeds them, so every Omnigent agy session runs without the user's global GEMINI.md / AGENTS.md, while the same user's plain agy gets them. Expected: an Omnigent agy session sees the same global rules as the user's interactive agy, the way settings.json (#5033), hooks.json (#6321), plugins and skill dirs are already carried into the isolated dir. Same "isolated --gemini_dir silently drops a user file" family as #5033, #6321 and #8353 (MCP servers). This one covers the rule files, which #8353 / #8359 do not touch. Steps to reproduce Controlled test against the real agy CLI, no Omnigent server needed: Have a global rule in the real Gemini dir, e.g. ~/.gemini/GEMINI.md containing Always remember the code word ALPHA. Build the isolated dir exactly as the runner does: from pathlib import Pat

Problem or use case The right-rail file browser can download workspace files, but there is no way to put a file from my machine into the workspace. On remote host runners and managed sandboxes that makes it hard to transfer anything (an image, archive, dataset or binary fixture) to the machine the agent works on. The existing paths don't cover it: Chat attachments land in a per-session cache outside the workspace (~/.omnigent/attachments/<session-key>/…). You can't choose the destination, and they never appear in the file browser. The editor's save (PUT …/filesystem/{path}) writes UTF-8 text only, so binary files can't be added and the rail can't create new files. Proposed solution Upload straight from the right-rail file browser, using the same resumable-upload pattern as Google Drive, Dropbox and tus. Where: drop one or more files on the tree root or on a folder row, or use an Upload button that opens the native file picker. Clearly "upload", not "attach": the file-browser dro

Minor nitpick: in a given matching package in a suggestion, master appears first but then releases are not in reverse chronological order.

Is your feature request related to a problem? Please describe. PyRIT now requires Python >=3.11 (currently <3.15), and Ruff targets py311. We can use Python 3.11 features consistently across supported versions, simplify older compatibility patterns, and improve typing, diagnostics, and async lifecycle management. Some features are already partially adopted; the opportunities below are investigations, not instructions to replace every existing pattern. Describe the solution you'd like How to participate: ONE opportunity at a time Claim exactly ONE checklist item at a time by commenting on this issue thread with its ID (for example, P311-01) and a short description of what you intend to investigate. Do not start multiple items or claim a bundle. Wait for confirmation here before treating the item as reserved. Claims are processed in comment order, and this issue is checked approximately every three hours. You must open a PR within five days (120 hours) of your claim comment. The confi

Description SnowflakeHook supports Workload Identity Federation (#68107) but only forwards workload_identity_provider, token and token_file_path. snowflake-connector-python>=4.0.0 also accepts workload_identity_impersonation_path: roles (AWS) or service accounts (GCP) to impersonate before authenticating, so Snowflake trusts the last identity instead of the workload's own. Proposal: read workload_identity_impersonation_path from the connection extras (list or comma-separated string) and pass it to the connector. Use case Local Airflow runs with developer SSO credentials for AWS. Snowflake should trust one dedicated role per deployment, not every developer's SSO role. With an impersonation path, the connection assumes that role for Snowflake only, and everything else keeps using the SSO credentials. Today this needs a custom hook. Are you willing to submit a PR? Yes

GPUStack version v2.3.0rc2 Operating System & CPU Architecture No response GPU No response ▶️ Steps to reproduce Deploy two deployments: 1 PD disaggregation deployment and 1 normal deployment. Run a benchmark with the PD deployment. Clone the benchmark; the target will be changed to the normal deployment. It seems the UI always tries to select a target instance, which is not applicable for a PD disaggregation deployment, so the clone doesn't keep the target. ✅ Expected result No response ❌ Actual result No response 🔍 Accelerator detection diagnosis (if applicable) No response 🐳 Model deployment / container diagnosis (if applicable) No response Additional Information No response

We've recently added more Rust structs annotated with #[pyclass(..)], like PyCircuitData and PyDagCircuit, getting closer to a clean separation between the PyO3 API layer and the core Rust model. However, there is an inconsistency in naming convention of methods in these structs when in comes to the use of the py_ prefix. Historically, we started to use the py_ prefix to clearly differentiate between Python-facing methods (#[pymethods])) and pure-Rust methods in monolithic Python/Rust struct (e.g. in CircuitData before the PyCircuitData split). Now that we have a clean split in more major structs, we should aim for a cleaner, and hopefully less noisier naming convention. Personally I'd prefer to omit py_ prefix from the #[pymethods] methods of a struct PyFoo of some pure-Rust Foo struct, as the Python-facing nature its methods should be clear from the context. I'd keep the py_ prefix for standalone #[pyfunction] functions though. Other ideas are welcome, as long as we agree on a consis

Feature, motivation, and pitch Fully migrate the GPU backend on main to ModelRunnerV2 and retire all ModelRunnerV1-specific code and execution logic. This is a complete migration, beyond adding an optional V2 execution path. All existing GPU E2E cases must also migrate to ModelRunnerV2 while preserving their scenario coverage and assertions. A separate V2 smoke subset is not sufficient. Proposed change Inventory the existing GPU V1 runners, worker selection branches, model integration, metadata preparation, graph lifecycle, compatibility patches, configuration, and tests. Map each supported behavior to its V2 replacement and close capability gaps before removing the old implementation. Make ModelRunnerV2 the sole supported runner architecture for the GPU backend. Migrate Attention execution and remove FFN-side dependencies on V1 internals; a V2 configuration flag alone must not leave FFN execution dependent on a V1 implementation. Keep connector-driven FFN responsibilities explicit wh

We could develop a recurrent task (that operates with batches and leverages redis task-scheduler for scalable mode, like other tasks) that takes similar non-suspicious requests from inactive ips (1 week inactivity) and crunches them in a single one. This could dramatically improve performance since the most db-expensive queries are on access-logs table, which is filled with useless non-suspicious requests. An example would be: GET /dasidaniodna GET /daefndisjd GET /sdleijfwmi GET /adlkndawndoia GET /test | | Crunched to V GET /dasidaniodna, ... GET /test

What's wrong The first-run welcome panel sends bug reports to the upstream project's discussions (harvard-edge/cs249r_book), not to TrenTorch. Where TrenTorch_CLI/platforms/cli/main.py L219-220, in _show_first_run_welcome: 🐛 PRE-RELEASE: We're looking for bugs and feedback! Found something? → github.com/harvard-edge/cs249r_book/discussions Repro Delete user_data/ (or use a fresh clone) and run tren. The panel prints once, on first run. Expected behavior Point to this repo's issue tracker: github.com/TrenTorch/TrenTorch/issues. Check platforms/cli/tests/ for any test that asserts on the old URL. (The tren system update command has the same upstream-repo problem; that's tracked separately.)

What's wrong tren --version reports 1.0.0. tren system info, tren system health and tren system update report the installed TrenTorch version as 0.1.0. Where TrenTorch_CLI/data/trentorch/__init__.py L14-26. _get_version() reads Path(__file__).parent.parent / "pyproject.toml", which is data/pyproject.toml. That file doesn't exist (the real one is TrenTorch_CLI/pyproject.toml, one level further up), so the except/fallthrough returns the hardcoded "0.1.0". The CLI's own copies (platforms/cli/__init__.py, platforms/cli/main.py) resolve the right file, so the two disagree. Repro tren --version # Tren⚡️Torch v1.0.0 tren system info # TrenTorch Version 0.1.0 tren system update --check # Current version: v0.1.0 tren system health prints the same v0.1.0 for the trentorch package. Expected behavior All of them show the version in pyproject.toml. Smallest fix: resolve pyproject.toml by walking up from __file__ (as core/modules.py::_find_project_root does) instead of a fix