Welcome to Python for the Lab discussions forum!

[aquilesC]

This is the place to ask your questions concerning Python for the Lab.

If you faced problems following the tutorials, or the book, please ask them here.

If you have any trouble with controlling instruments, we will do the best we can to support you.

[Dr-Br0t]

Hi, when could we buy the "advanced python for the lab" book?

[aquilesC]

The plan is to release it before the end of the summer. I am currently reviewing the introductory book (that needed some urgent updates) and as soon as I'm done, I'll focus on completing the advanced book which is ~50% done at the moment.

[Dr-Br0t]

Hi

[aquilesC]

I think I was a bit too ambitious with the timeline I've set for myself. Other projects came my way and the book was placed with lower priority. If you've signed up for the newsletter you'll get a notification as soon as it's out.

[Dr-Br0t]

Hello, Mr. Aquiles, do you have any update regarding your excellent book?

[martinknapp18]

Hi, i attended the PFTL course a few weeks ago now and have been practicing since. I've found it quite easy to apply the techniques to some of the projects i'm working on. Although, I'm having trouble with the final aspect of the course which was packaging up the code for someone else to use. It's difficult to remember the steps from the slides alone, is this covered in the book, or is there anything else you can share?

Also, i've come across the pyinstaller module which can package everything up as an .exe, do you have any tips on using this with the folder structure and project format you use in the course?

[aquilesC]

Hello Martin!

Thanks for reaching out. Indeed, I am working on making those topics clearer.

In a nutshell, the first step is to make your program installable. I always default to creating a setup.py file because I find it clear and easy to reproduce. You can find an example of such file here.

Once that is in place, you can install your program running:

pip install -e .

(The -e is there to install it in editable mode, so you can keep modifying the code without having to re-install each time). If you work carefully, you can specify the dependencies your program needs (see here which will make your program very easy to distribute and to get to work. If you publish your code on a repository (like Github or Gitlab) you can directly install the program:

pip install git+https://github.com/username/repo.git

Regarding PyInstaller, it is a great tool to share code, since it packages everything (including the Python interpreter) in a convenient .exe file (which is actually a self-extracting zip file). The usefulness of the PyInstaller route depends on who the intended users are and the safety context in which you work. If they are not python-aware (thus not confident running pip install, creating environments, etc.) then it would be a nice route to follow. On the other hand, you'll be sharing .exe files around, and their execution may be limited for safety reasons (many e-mail servers would block the send/receive of a .exe file, for example).

Is this answering your questions?
Let me know if anything was not clear!

[martinknapp18]

Thanks for the quick response! yes that did answer my question, although I have a few more now. I was missing the '.' in 'pip install -e .'. I was able to get everything working from then onwards.

Essentially when you move to the other PC (where you want to distribute code to), when the terminal is first opened, you always need to activate the venv? i.e, '../Scripts/venv/activate'? otherwise commands like pip and python won't work? in the course we saved venv outside of the pycharm project folder, is it ever really useful to save it inside?

The 'pip install git+' does seem like a useful command, although i found it didn't download all the files in the repository i.e. it left out config.yml which meant that i couldn't run the code. Is it better to 'git clone '? then use 'pip install -e .'?

[aquilesC]

I strongly suggest you to work with environments and not directly on the root installation of Python. So what you describe is correct, first activate the environment. If Python was installed "globally" (I'm not a heavy Windows user, so the installation process is a bit fuzzy in my mind), when you start the terminal you can run python and pip without activating any environment. However, that's the base Python and it can be a bit risky to mess with it, since you have no idea what other projects and tools in the computer are relying on it.

The idea of saving the environment on its own folder (and outside the code folder) is because 1) you don't really want to send the environment through git, since environments can be created from text files (like requirements.txt), 2) environments can be shared across projects, 3) the same project can be tested under different environments, for example with different versions of packages.

Keep in mind the 'config.yml' is part of the examples folder, not of the code. That is why it is not available. In that specific context, the user that installs the software should create their own config file for the program to run. If that behavior is not a good solution, the code should take care of creating an initial version of the config file.

For example, that's what I do here. It first checks if the config file exists and if not (the program is running for the first time) it creates it with some defaults. (I was using json instead of yaml in that specific example, but it's the same principle).

Using git clone to fetch the project or installing it with pip install without cloning first, is context dependent. If you want your code to be easily shareable, running a single command is much simpler than cloning and installing from within (and can be easily automated by including it in requirement files, for example).