Develop Reference

Dynamically importing .py files after compiling

I've tried looking online and I'm honestly lost at this point.
I'm trying to find if there's a way to import python scripts and run them AFTER my Python program has been compiled.
For an example, let's say I have a main.py such that:
import modules.NewModule
a = NewModuleClass()
a.showYouWork()
then I compile main.py with pyinstaller so that my directory looks like:
main.exe
modules/NewModule.py
My end goal is to make a program that can dynamically read new Python files in a folder (this will be coded in) and use them (the part I'm struggling with). I know it's possible, since that's how add-ons work in Blender 3D but I've struggled for many hours to figure this out. I think I'm just bad at choosing the correct terms in Google.
Maybe I just need to convert all of the Python files in the modules directory to .pyc files? Then, how would I use them?
Also, if this is a duplicate on here (it probably is), please let me know. I couldn't find this issue on this site either.

You may find no detailed answer simply because there is no problem. PyInstaller does not really compile Python scripts into machine code executables. It just assembles then into a folder along with an embedded Python interpretor, or alternatively creates a compressed single file executable that will automatically uncompress itself at run time into a temporary folder containing that.
From then on, you have an almost standard Python environment, with normal .pyc file which can contain normal Python instructions like calls to importlib to dynamically load other Python modules. You have just to append the directory containing the modules to sys.path before importing them. An other possible caveat, is that pyinstaller only gets required modules and not a full Python installation, so you must either make sure that the dynamic modules do not rely on missing standard modules, or be prepared to face an ImportError.

Is there a way to reference Python projects in VS Code?

I am working on a bunch of Python 3 scripts that are organized like so:
/workspace
/project_one
script_a.py
script_b.py
/project_two
script_c.py
There are many project folders and every once in a while, one is added, with varying numbers of .py files inside. I want to be able to import each script from each folder in each other script, but since I switched to VS Code, I have no idea how to do that. I tried adding __init__.py files in every directory and various syntaxes for the import statements.
From what I've read, this way of importing is not actually supported in Python 3 (which I find weird, isn't it one of the most common use cases of the import system?)--yet it was really easy in Eclipse with PyDev where I could just go into the project options and select "referenced" projects. I was then able to write e.g. import project_one in script_c.py and it worked perfectly. I now assume that maybe the absolute paths were stored in some Eclipse project file that way? Does VS Code have such a feature? If not, how would I continue programming without having to use some of the "dirty hacks" I read that maybe enable this?

Python built-in module for handling Excel files

I know similar questions have been popular in the past, but none refers to my problem. I'm looking for a way to read data from Excel file in Python, but I'm strongly against using non-builtin modules.
The reason why is that in my case Python is a component of another software, so incorporating additional module would require from every user knowledge about how to use pip, which Python installation on your pc should one install module into, etc. The solution must not require any additional actions from user.
I can read CSV files with Python builtin easily, so that could work, but how can I convert Excel to CSV in the first place? Or is there a way to read Excel directly?
Edit: It is Python 2, that is used in this software.
Edit2:
Anyone minds explaining the downvote? I think this isn't a question about a ready solution or module, but rather a method and is well detailed. It is not always possible to use external modules, so this is an actual problem. If it is not possible at all though, then I would simply expect an answer instead of -1.

Not really the prettiest solution, but you could download the complete code repository of one of the excel handling packages for python (openpyxl for example) and put these files in the same directory as the python script that you're going to run. Subsequently you can do an import of these local package files in your script.
Note: if the excel handling package has dependencies on other packages, then you'll need to download these as well.

Do Python module imports depend on how the code is run? [duplicate]

This question already has answers here:
Relative imports for the billionth time
(12 answers)
Closed 5 years ago.
I don't think any language causes as much headache as python in so simple a thing as importing other source files. So here is the question:
Do my module imports need to depend on how the code is supposed to run?
I have the following directory structure:
./__init__.py
./config.py
./kmer
./kmer/__init__.py
./kmer/__main__.py
./kmer/__pycache__
./kmer/__pycache__/__init__.cpython-36.pyc
./kmer/__pycache__/__main__.cpython-36.pyc
./kmer/__pycache__/bed.cpython-36.pyc
./kmer/__pycache__/config.cpython-36.pyc
./kmer/__pycache__/reference.cpython-36.pyc
./kmer/__pycache__/sets.cpython-36.pyc
./kmer/bed.py
./kmer/config.py
./kmer/reference.py
./kmer/sets.py
I wish to import a module inside the khmer from another module inside the kmer package. Simple?
So I add this at the of the bed.py:
import reference
import config
import sets
Now thing will work just fine if I run python bed.py from the kmer directory. Also things are fine if I come back one directory and call python kmer/bed.py. Seems like python searches for imported modules relative to the given file.
Again running it as python -m bed from the kmer directory works fine but coming back one directory and running python -m kmer.bed results in module errors. Here it seem like python looks for modules inside the interpreter's current directory which could be anywhere on the file system so imports relative to it shouldn't work.
This basically means that the imports should depend on how the code is going to be run which makes no sense. I'd appreciate some explanation on how this is supposed to work.
I've looked at quite a lot of resources including the answer to this question which although very detailed (one of the best descriptions I've found actually) doesn't solve my problem and also doesn't provide proper examples.
Update: I believe this question is more focused on a different aspect of relative import, more precisely how different methods of running the code affect the imports, than the one it is marked as a duplicate of. Thats why I mentioned the other question in first place. Hence I don't think this should be a duplicate.

When writing a package, you must consistently treat it as a package. First, that means using relative imports within the package: write from . import reference in bed.py.
It also means the answer for how to access it is always the same: put the directory containing kmer onto sys.path (usually via PYTHONPATH). This is true even if running some module in the package as the script, so it must be python -m kmer.bed.
Unfortunately, it's a bad idea to run a module inside a package as a script: the module's file is still eligible to be imported again under its proper name (rather than the __main__ used the first time). The only robust solution is to write a __main__.py and run the package as the script, avoiding overloading a public module name.
Finally, don't pay much attention to the "feature" of Python putting the script's directory on sys.path. This is useless other than for toy problems where you don't care about name collisions, since any script whose directory would be useful on sys.path is necessarily a module (except in case of tricks like making its name not be an identifier). Moreover, if you want your library to be available to scripts installed elsewhere, it needs to get on sys.path some other way anyway.

What is the argument for Python to seemingly frown on importing from different directories?

This might be a more broad question, and more related to understanding Python's nature and probably good programming practices in general.
I have a file, called util.py. It has a lot of different small functions I've collected over the past few months that are useful when doing various machine learning tasks.
My thinking is this: I'd like to continue adding important functions to this script as I go. As so, I will want to use import util.py often, now and in the future, in many unrelated projects.
But Python seems to feel like I should only be able to access the code in this file if it lives in my current directly, even if the functions in this file are useful for scripts in different directories. I sense some reason behind the way that works that I don't fully grasp; to me, it seems like I'll be forced to make unnecessary copies often.
If I should have to create a new copy of util.py every time I'm working from within a new directory, on a different project, it won't be long until I have many different version / iterations of this file, scattered all over my hard drive, in various states. I don't desire this degree of modularity in my programming -- for the sake of simplicity, repeatability, and clarity, I want only one file in only one location, accessible to many projects.
The question in a nutshell: What is the argument for Python to seemingly frown on importing from different directories?

If your util.py file contains functions you're using in a lot of different projects, then it's actually a library, and you should package it as such so you can install it in any Python environment with a single line (python setup.py install), and update it if required (Python's packaging ecosystem has several features to track and update library versions).
An added benefit is that right now, if you're doing what the other answers suggested, you have to remember to manually have put util.py in your PYTHONPATH (the "dirty" way). If you try to run one of your programs and you haven't done that, you'll get a cryptic ImportError that doesn't explain much: is it a missing dependency? A typo in the program?
Now think about what happens if someone other than you tries to run the program(s) and gets those error messages.
If you have a library, on the other hand, trying to set up your program will either complain in clear, understandable language that the library is missing or out of date, or (if you've taken the appropriate steps) automatically download and install it so things are ready to roll.
On a related topic, having a file/module/namespace called "util" is a sign of bad design. What are these utilities for? It's the programming equivalent of a "miscellaneous" folder: eventually, everything will end up in it and you'll have no way to know what it contains other than opening it and reading it all.

Another way, is adding the directory/you/want/to/import/from to the path from within the scripts that need it.
You should have a file __init__.py in the same folder where utils.py lives, to tell python to treat the folder as a package. The file __init__.py may be empty, or not, you can define other things in there.
Example:
/home/marcos/python/proj1/
__init__.py
utils.py
/home/marcos/school_projects/final_assignment/
my_scrpyt.py
And then inside my_script.py
import sys
sys.path.append('/home/marcos/python/')
from proj1 import utils
MAX_HEIGHT = utils.SOME_CONSTANT
a_value = utils.some_function()

First, define an environment variable. If you are using bash, for example, then put the following in the appropriate startup file:
export PYTHONPATH=/path/to/my/python/utilities
Now, put your util.py and any of your other common modules or packages in that directory. Now you can import util from anywhere and python will find it.