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.py
is 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
subprocess
with the optionshell=True
the 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