Subpar not generating a correct PAR file about subpar HOT 4 CLOSED

Thanks for the bug report, the detail you included was very helpful. I've found two different bugs are involved, and created separate issues for them: issue 11, issue 12.

Also, not a bug, but there is a Python standard library module called "code" which shadows your package "code". This triggers one of the bugs, and makes the error message more confusing than it needs to be.

While they are being fixed, you can workaround the first bug by adding an imports attribute to your BUILD target:

par_binary(
    name = "some_app",
    srcs = ["some_app.py"],
    imports = [".."],
    deps = [
        "//code/util:some_library",
        "//code/util:some_log",
    ],
)

Unfortunately, I can't think of a good workaround for the second bug other than renaming your "code" directory to something else.

from subpar.

Thanks for a quick response. I think I might have added an unnecessary confusion by substituting 'myprojectname' with 'code' on the entire output, so that shadowing issue was a red-herring here. Sorry about that.

The issue I'm having seems to be a bit different. Perhaps I misunderstood what support._setup() was intended to do.

I thought its goal was to append (or rather prepend) the archive_path and directories matching archive_path/* to sys.path and do so without tweaking imports in par_binary rules which seems like an unnecessary hassle (i.e. the deeper in the directory structure you delve into, the more '../../..' you'd need to manually add to make it work).

Do you agree that the stub_file produced by the vanilla py_binary rule does this correctly?

repo_dirs = [os.path.join(module_space, d) for d in os.listdir(module_space)]
repositories = [d for d in repo_dirs if os.path.isdir(d)]
python_path_entries += repositories

And then, a bit below:

new_env['PYTHONPATH'] = python_path
os.environ.update(new_env)

If I got this right, I'd be happy to send a patch for this and the related bugs. Thanks for help and please let me know.

from subpar.

Short answer: Yes and yes

Long answer: I'm a bit conflicted. There are many different ways to structure source code, and it's hard to add implicit behavior that works for everyone. The more things we add to sys.path, the more possibilities there are for strange name conflicts to arise. So I lean toward explicit: explicit workspace names (e.g. the "subpar" workspace is named "subpar"), explicit "imports" attributes in BUILD rules when needed, and longer package lines like "import subpar.compiler.stored_resource" vs just "import compiler.stored_resource".

However, I also think the benefit from exactly matching the behavior of Bazel's stub file trumps this concern. So, yes.

Note that the additional entries should actually be inserted immediately after sys.path[0] (which is the par file itself).

from subpar.

Should be fixed now. Please verify.

from subpar.