conda / conda/menuinst

Rethink menuinst for existing Desktop files or App bundles.

Open
#371 3 comments 0 reactions 0 assignees View on GitHub
stale type::feature
Dominant language
Python
Stars
50
Forks
49
Avg merge
1d 11h
Merged PRs (30d)
16

Description

### Checklist

- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate

### What is the idea?

We've been trying to package some Electron / Tauri / Rust applications and on macOS and Linux they usually already create their own App Bundle / Desktop file.

I was thinking: instead of trying to push everything through the menuinst.json file, we could perhaps also enable menuinst to copy/symlink an existing App Bundle or Desktop file to the right place, and possibly adjust it slightly to enable the conda activation.

That would make menuinst super flexible, and existing bundles (build outputs) work more easily instead of creating a new file or trying to wrap a App Bundle.

### Why is this needed?

Make the experience nicer for packaging desktop apps.

### What should happen?

Discussion!

### Additional Context

_No response_

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing how menuinst.json currently represents menu items and how existing macOS App Bundles and Linux Desktop files are handled. The issue needs an agreed design for copying or symlinking those existing artifacts and optionally adjusting them for conda activation; done means the behavior and scope are decided before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, python, rust, tauri
Domain
desktop, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.