Ideally, each directory or program that is made to be used by independent projects should be transformed into an installable package - for this, the most common method is to create a file setup.py (/a/281961/500). When this is done, just use import <nome_do_outro_projeto> (even if it is a single file), in a Python environment where it is installed and everything works.
As this involves some bureaucracy, it is not always ideal for times when we just need to have something working - all that is really needed is for the directory where the other file is a component of the list on sys.path .
If you go in interactive mode and type
import sys
sys.path
will see a list of strings, each string is a folder where Python will fetch packages and modules to import. It starts with an empty string, '', indicating that the first directory is the current directory - so import <arquivo> works to import arquivo.py in the same folder.
So, if you’re working with a fixed directory structure, and you don’t want to change scripts from place (okay, if you’re mounting a Ocker, bad if it’s a desktop development usage machine: it’s not productive to copy directory structures to another machine)It’s just, before the command import, import the sys and change the list sys.path, including in it the directory where is the script you want to import:
import sys
sys.insert(1, "/camino/para/outra_pasta/")
And from there, you can do import <arquivo> and it will work.
At this point I draw attention: the idea of a multi-file system is to use the import and all run within the same job python, even if you use modules like multiprocessing.
When you use subprocess.call you start another task completely separate from the current process - it may be a Python program, but it could be any other program - and the communication has to be done, if there is "manually" by stdin and stdout. It’s not necessarily bad - but it can only have some advantages if they are very independent things - for example, the project that calls the other is a generic graphical interface to trigger the other job. But even in these cases, if the other project is in Python, if you import the other project as a library - you can call the functions and instantiate classes of the other project, passing parameters that are available in the project that "makes the call".
In short - try to organize your projects in ways that are unimportable, and can be used as a single Python process, using "import".
If the
main.pyis in another directory, you must specify it in the command, something likeoutra/pasta/main.py– Woss
I tried already with the specified path, it does not work. I did not understand well if it is on account of the parameters. Maybe the command used isn’t what I’m using.
– Rony Deikson Santana
I put something like
cmd = "C:/Users/EU/PycharmProjects/Pasta1/main.py -u ABCD -p 1234" subprocess.call(cmd, Shell=True)But it didn’t work.– Rony Deikson Santana
when you use the
subprocesswith the optionshell=Truethe string with the file path is not interpreted by Python - it is passed to S.O. - and it does not recognize "/" as a directory separator - re-rescues the path with\, always putting two at a time -\\\- to prevent it being used as an escape character.– jsbueno