Sharing logic between different virtual environmets - virtualenv

I currently have two working python virtual environments and would like to share some code between them so that I don't need to have that logic on both environments. Do I need to build a custom package to make this possible?
I have tried creating a shared folder on both projects which is a symlink to a common folder and is working fine, however this seems to break the essence of virtual environments doesn't it?
This is my directory structure:
├── common
├── env1
│   ├── env1-venv
│   └── src
└── env2
├── env2-venv
└── src
├── shared
├── ...

Related

Image-specific layers

I am building multiple poky-based images for different projects but using the same build directory (because it seems a bit overkill to have a new clone of yocto for every project).
But I happen to have my images conflicting with each other because of the .bbappend they define. For instance, I have two images that each extend the hostapd recipe in order to define their own configuration file.
Let me illustrate with an example. I have two layers that each define an image: first-project and second-project. Each has its own layer, because they belong to a different repository: meta-first-project and meta-second-project. And both use hostapd. So they projects look like this:
meta-first-project:
.
├── conf
│   └── layer.conf
├── recipes-connectivity
│   └── hostapd
│   ├── hostapd
│   │   └── hostapd.conf
│   └── hostapd_%.bbappend
└── recipes-first-project
   └── images
   └── first-project-image.bb
meta-second-project:
.
├── conf
│ └── layer.conf
├── recipes-connectivity
│ └── hostapd
│ ├── hostapd
│ │ └── hostapd.conf
│ └── hostapd_%.bbappend
└── recipes-second-project
└── images
└── second-project-image.bb
With a different hostapd.conf for each.
The conf/bblayers.conf file looks like this, including both layers:
conf/bblayers.conf:
BBLAYERS ?= " \
/home/user/Documents/yocto/poky/meta \
/home/user/Documents/yocto/poky/meta-poky \
/home/user/Documents/yocto/poky/meta-yocto-bsp \
/home/user/Documents/yocto/meta-first-project \
/home/user/Documents/yocto/meta-second-project \
When I run bitbake first-project-image, I want it to use the hostapd_%.bbappend in meta-first-project and not the one in meta-second-project. But my understanding is that both will be evaluated, meaning that meta-second-project/hostapd_%.bbappend will have an impact on my first-project-image, which I don't want.
Is there a way to solve that, or should I have two build folders (and download, build and duplicate everything there)?
For instance, I thought about checking something like this in the bbappend of hostapd in meta-first-project (pseudo-code):
if (${IMAGE_BASENAME} == "first-project-image") {
// write the whole bbappend here
}
Such that this bbappend is only considered when building the image first-project-image. However, ${IMAGE_BASENAME} does not seem to be set in the hostapd recipe...
Another idea, similar to COMPATIBLE_HOST and COMPATIBLE_MACHINE would be to define a COMPATIBLE_IMAGE variable, but that does not exist.
You can't change the content of individual recipes based on an image, that is a simple and unavoidable constraint from the way the system is built. The reason why is that the packages are constructed from the recipes long before the rootfs/image is built so it has no influence over it. All images use the same package set. You can reuse the same downloads, build directory and tree and simply change bblayers.conf to use one layer or the other and things will work but there isn't a way you can make both images work in the same configuration.
There are other options. You could separate out the hostapd change into two different recipes and then have each image include the correct content that way by including the right recipe. You could also tweak the image at construction time (see rootfs-postcommands.bbclass). You could specify two different DISTRO settings and switch between those, or maybe switch between configs depending on a MACHINE setting (making the hostapd recipe machine specific) but those two do require configuration changes between the images too. Multiconfig may or may not also be something which could help, it is hard to say from the information here.
There is no COMPATIBLE_IMAGE option as recipes are common to all images, that is just the way the system is designed and works, it doesn't build a new recipe set per image.
You can create your own COMPATIBLE_IMAGE variable and use it to conditionally append the conf file.
For example, in your meta-first-project/recipes-connectivity/hostapd/hostapd_%.bbappend:
SRC_URI_append = " ${#bb.utils.contains('COMPATIBLE_IMAGE', 'first-project-image', 'file://hostapd.conf', '', d)}"
And for your second image as well in
meta-second-project/recipes-connectivity/hostapd/hostapd_%.bbappend:
SRC_URI_append = " ${#bb.utils.contains('COMPATIBLE_IMAGE', 'second-project-image', 'file://hostapd.conf', '', d)}"
Now, the first conf file will appended to SRC_URI only if COMPATIBLE_IMAGE contains first-project-image.
You can define COMPATIBLE_IMAGE now anywhere you want, you can set it in local.conf for testing purposes or in your image recipe:
COMPATIBLE_MACHINE = "first-project-image"
You can use the COMPATIBLE_MACHINE variable now anywhere you want with the same principle.
Now, if you are appending to some hostapd tasks and using the conf file make sure to test on the variable before using it, and if hostapd understands directly the conf file and used without overriding some task you don't need to test on the variable.
Hello your use case seems compatible with BBMASK.
"Prevents BitBake from processing recipes and recipe append files."
Taken from documentation
With this variable, you can hide the bbappend you don't want to interact with your layer. Starting from your example, you'll have the following line in conf file of meta-first-project:
BBMASK += "meta-second-project/recipes-connectivity/hostapd"
But, if your two layers doesn't depends on each other, it is simpler to not reference them in their respective bblayers.conf. If the meta-second-project
is not necessary to build images provided by meta-first-project, simply remove meta-second-project from bblayers.conf.
I'm guessing from your post that the two projects are using the same MACHINE?
If they were different MACHINEs you'd have a lot more tools...
What I would do is probably create a hostapd-foo.bb with require hostapd.bb.

Setup with Swagger UI and Swagger Editor using yaml split across mutliple files

I would like to use swagger for our project, which is rather big. Documenting the whole REST-API in one single yaml file would be too much, so I would like to split it into several yaml files.
First I tried to use Swagger UI simply by downloading it an opening its index.html. That works until the point that I split the yaml into multiple files, as I got CORS errors then. To circumvent them, I simply deployed the Swagger-UI Folder, with my projects yaml files inside it as artifact to my tomcat.
The folder structure of the artifact looked like this:
swagger_ui
├── index.html
└── api
├── root.yaml
├── paths
│ ├── path1.yaml
│ ├── path2.yaml
│ └── ...
└── schemas
├── schema1.yaml
├── schema2.yaml
└── ...
Now all CORS errors were gone, as my references are now all within the same origin (eg. "http://localhost:8080/swagger_ui")
So far, so good.
Now I wanted to have a simple way of editing the files using Swagger Editor.
In Swagger Editor, I click on File --> Import URL and import my root.yaml file. Now I get a bunch of errors saying the URLs to "paths" and "schemas" can not be resolved... Which makes sense, as I only imported root.yaml and the path and schema files are stored on a completely different server.
So my current approach is to deploy Swagger Editor alongside Swagger UI in my tomcat.
The current folder structure looks like this:
swagger_ui
└── index.html
swagger_editor
└── index.html
api
├── root.yaml
├── paths
│ ├── path1.yaml
│ ├── path2.yaml
│ └── ...
└── schemas
├── schema1.yaml
├── schema2.yaml
└── ...
I thougt I can use eg. "$ref: '../api/paths/path1.yaml'" to reference the the path1.yaml file from BOTH Swagger UI and Swagger Editor, but I get the Error:
Could not resolve reference: Tried to resolve a relative URL, without having a basePath. path: '../api/paths/path1.yaml' basePath: 'undefined'".
Aside from this error... Using ".." to go up one directory does not seem right in itself...
So the question is:
Which is the right way to set up a Swagger API Definition that has the following properties:
It is spread over multiple yaml files
It can be edited in Swagger Editor
It can also simply be visualized in Swagger UI
If my current approach is totaly wrong and there is a completely different approach, please tell me. It is no requirement to use tomcat or anything else I stated above. I just wanted to know if my approach makes any sense at all.

vscode generate large configuration files

I have noticed that the .vscode files have 1.4 GB in each folder that I open a code. Why these file have become so large? Is there any way to stop making these large files? I need to scp code folder between remote machine and I need to remove these files frequently.
I use version: 1.32.3 on Limux Mint 18.3. and the following extensions:
Python, C++, Prettier, Peacoke, GitLense.
.vscode/
└── ipch
├── 21fd2401553c84f8
│   ├── functions.ipch
│   └── mmap_address.bin
├── 944dcfa22b114a8c
│   ├── main.ipch
│   └── mmap_address.bin
└── 9f0098f535f71055
├── kuramoto.ipch
└── mmap_address.bin
4 directories, 6 files
Thank you for any guide.
The files in the ipch folder are IntelliSense cache files generated by the C/C++ extension. The maintainer has described how you can the customize cache path and size limit here.

How to change the sitename setting with Pelican?

I'm a new learner of Pelican.
I have created my personal website including basic settings and some pages by using Pelican, and the following hierarchy has already existed on the local PC:
myblog/
├── author
├── content # Content file (Push on GitHub)
│ └── (pages)
├── output
├── theme
├── develop_server.sh
├── fabfile.py
├── Makefile
├── pelicanconf.py # Main settings file
└── publishconf.py
Unfortunately, I set the wrong sitename from the beginning when I install Pelican. Right now I'm struggling to change the incorrect sitename from "test" to "XXX's blog". I can rewrite sitename directly in the document called pelicanconf.py. But after that, there's no way to push it on GitHub. So the appearance of my website remains stable.
The only thing I could do is to update the page content again and again, but not the sitename. Because only the content folder is synchronized with my remote GitHub repository.
Is there anyway to change the sitename setting?

using blueprints on Hierarchical APIs in Sails

I've got a models folder (and corresponding controllers folder) that looks like this:
.
├── Pets
| ├── User.js
│   └── Pet.js
└── UserManager
   ├── User.js
   ├── Group.js
   └── Organization.js
and would like to use REST blueprints of the type
POST to foosite.com/userManager/user
or at least
POST to foosite.com/user
Is there an easy way to do this?
Corresponding shortcut routes and action routes would also be nice.
Thanks!
You can use controllers in subfolders and specify their corresponding model.
Currently models do not work in subfolders.
Check out this answers
Create subfolders in Sails.js /api/controllers
Is it possible to group controllers in sails using subfolders?