Proper management of i.e., PythonPath?

[davidbernat]

Description

Hey excellent OpenCode team. In my third week of using OpenCode, as a first time augmented coded, and ten year scientist develop, I have been seeing a lot of immense capability in the OpenCode way of writing software.

I am writing this about the OpenCode c. 1.1.14 Build & Plan integrations with a typical model (i.e., Big Pickle).

I notice the engines keep making the same import mistakes predicated on its default pattern for code inspection. For instance, I am working with a local dev version of my proprietary package CloudNode. For example, let us say I have written this prototype feature class ProcessingPipeline in a suitably named file.

# app.py
from cloudnode.base.iaas.extensions.pipelines import ProcessingPipeline
import datetime
import os

# other code and such

pipeline = ProcessingPipeline(**arguments)
pipeline.doSomething()

I can ask Plan to create a PRD for ProcessingPipeline with a simple prompt i.e, "We need to create a PRD for the prototype ProcessingPipeline class in @app.py, and do a literature search to compare its functionality to open source third-party alternatives. That will be the purpose of this session."

And, Plan will always do a grep/find bash search into the filesystem (i.e., search for files in the cwd that contain something that looks like a class named ProcessingPipeline) instead of the "more logical" (and more intuitive) decision to grep app.py, find either its class definition in that file or an import statement, and leverage the PYTHONPATH variable to simply and directly retrieve the specific code-coded class definition. All other options are inferior, and this hints that OpenCode is not approaching a "interpret code"-first approach (why not? and who is?). This notion of priority of directories of source code (i.e., PYTHONPATH) is universal across languages, so we are not talking about a Python problem here, but an entire ontological philosophy of OpenCode and coded-understanding. In this other ticket I describe similar cognition failures when using within IntelliJ which is more or less a use case of this more general problem set. (https://github.com/anomalyco/opencode/issues/6982)

This puzzles me though. After all, OpenCode will rapidly requires expansive bash read permissions to "solve" this "filesystem first" approach to identifying a code problem (you are funded by YC, after all) and also will ask for python run permissions on (simple) jerry-rigged code, such as (seriously) running a python -c "import module_name, os; print(os.path.abspath(module_name.__file__))" but why on Heaven & above would I be comfortable with giving over permission to run python code (generated by an LLM) that cannot even interpret the exact same line item from within the code context itself. That is exactly the wrong business and framework model (again, YC) and I am struggling to understand what I am being asked to give my computer over to (beyond an awesome chat spooling system which is genuinely fabulous).

I cannot say enough good things about OpenCode in many rooms of my corporate enterprise, but walk across the hallway and I have to laugh with the other MDs and LPs, and I mean that with the absolutely best of kindnesses.

These are addressable problems the market needs to know and understand. Let me know what you need from me. Until then this is a blocker of a basic day one situation, which either I have fundamentally misconfigured using the out of the box OpenCode (unlikely three weeks in but certainly plausible) or is "foundationally baked in to your [users'] future." Thank you guys so much for doing this (though you are funded so this is business model).

Warm regards. Cannot say enough how good and open this conversation is (and you can tell LinkedIn/YC that, and in an email).