-
-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying output directory and other compilation options for all Coconut files in the project #768
Comments
That command will only compile Currently, the compilation parameters used for automatic compilation are not adjustable, however. That could be added as a new feature here, but what compilation parameters are you looking to adjust? Automatic compilation already includes We could also definitely make automatic compilation default to some specific directory like |
Really? It does compile $ ls
file1.coco file2.coco
$ cat file1.coco
import file2
file2.func()
$ cat file2.coco
def func():
pass
$ coconut -v
Coconut: Version 3.0.2 running on Python 3.11.2 and Cython cPyparsing v2.4.7.2.1.1
$ coconut-run -l file1.coco
$ ls
__pycache__ file1.coco file1.py file2.coco file2.py
I've just realised that maybe I don't really need to adjust these parameters when invoking
Well, anyone using my Python code has to install pip dependencies anyway, and Coconut is just another pip dependency, isn't it? I'm mostly doing research code, and people using my code need an easy way to modify it, so releasing it in source form seems natural. Sometimes it's preferable to distribute the compiled code and minimise the number of dependencies, but source-only distribution is an important use case IMHO. Sure, running code with |
You must be importing |
The other things that are tricky about this mechanism of distributing Coconut code are:
Maybe another option that would resolve (1) could be to have a mechanism for allowing your package to automatically run |
It looks like |
Ah, yep, you're right, it is doing that. Automatic compilation is always enabled at the interpreter, and |
I agree, these are very good points. If something is a package, most users won't care about its source and will just use the API. It makes sense to distribute Coconut packages in their most efficient, compiled form, so that they can be easily imported from Python without much hassle or unnecessary dependencies. But my use case is much more experimental: I might want to try something out, run And again, if I want to send my code to a colleague for them to adapt it to their needs, it makes no sense to give them the compiled version, because they will have to modify my code anyway. This is the way many interpreted scripting languages are used, and Coconut can be used this way too. I'm just asking to make the compilation process a little less visible. |
BTW, one case that is unintuitive due to the fixed auto-compile options is when you run |
As of |
As of To get the new behavior, |
Say I have two files.
file1.coco
:file2.coco
:Now if I want to run file1.coco, e.g. with
coconut-run -l file1.coco
, the-l
option only applies tofile1.coco
and I have no way of changing the compilation options forfile2.coco
, is that right?Specifically, what I'm seeking is a method to automatically redirect all compiled Python files to a designated subdirectory like
__pycache__
. By doing so, it would help keep them organized and easy to remove or gitignore. That's similar to the rationale behind placing.pyc
files separately in__pycache__
rather than mixing them with the.py
files in a single directory.Not sure if that's one issue, or two related ones.
PS. Thanks for your great work. Coconut is awesome!
The text was updated successfully, but these errors were encountered: