Hey everyone I m building a repo that contains multiple pulu

Question

Hey everyone I m building a repo that contains multiple pulumi projects and I ran into the same issue described and that is to say you can t import in ` main py` modules from parent directories Mostly the solutions that have been suggested are Either hack sys path in some way or another Install the pulumi repo itself as a package as described I was wondering if in the meantime someone had come up with a preferrable solution

clever-painter-96148 · Answer

My pulumi programs are very minimalistic and I put all my logic in a library package So I can use standard python tooling and relative imports in the actual package without having to hack around stuff

millions-pharmacist-626 · Answer

gt I put all my logic in a library package So you create a separate folder like `logic` that sits next to your projects and add that as a dependency

clever-painter-96148 · Answer

Yes

millions-pharmacist-626 · Answer

that s an interesting alternative

millions-pharmacist-626 · Answer

what would be the pros and cons of doing what you recommend vs installing the project as a local package with either `poetry install` or `pip install `

clever-painter-96148 · Answer

When you wrote add that as a dependency I understood poetry add

clever-painter-96148 · Answer

so I do not understand your last question

millions-pharmacist-626 · Answer

nono it s exactly what I meant `poetry add mylocalpackage`

clever-painter-96148 · Answer

In `project gke cluster pyproject toml` ``` tool poetry dependencies python = ^3 10 pulumi = ^3 48 0 pulumi gcp = ^6 44 0 trc hpc lib gke cluster = path = lib gke cluster develop = true ```

millions-pharmacist-626 · Answer

understood

millions-pharmacist-626 · Answer

out of curiosity what s in `pyproject toml` in the lib gke cluster

millions-pharmacist-626 · Answer

cause I see you also have a lockfile and a makefile

clever-painter-96148 · Answer

``` tool poetry name = trc hpc lib gke cluster version = 0 0 0 authors = x lt x x gt description = GKE cluster deployment library tool poetry dependencies python = ^3 10 pulumi = ^3 48 0 pulumi gcp = ^6 44 0 pulumi kubernetes = ^3 23 1 tool poetry group dev dependencies black = ^22 12 0 pyright = ^1 1 283 pytest = ^7 2 0 pylint = ^2 15 8 build system requires = poetry core build backend = poetry core masonry api tool black line length = 79 tool pyright typeCheckingMode = strict ```

clever-painter-96148 · Answer

I have a lockfile in every package of my monorepo so in CI I can poetry install every package individually

clever-painter-96148 · Answer

so I can run static analysis on them

clever-painter-96148 · Answer

but only when they change vs having 1 CI process that works on everything

millions-pharmacist-626 · Answer

right makes sense

clever-painter-96148 · Answer

The Makefile is just to normalize CI commands ```$ cat lib gke cluster Makefile lint pylint trc hpc lib gke cluster tests test pytest verbose $ cat project gke cluster Makefile lint pylint py test true```

clever-painter-96148 · Answer

because pylint is not happy looking at the whole pulumi program folder it expects a python package and because I do no write tests for the program and pytest fails when there are no tests

millions-pharmacist-626 · Answer

understood tyvm If you don t mind me asking I have one last question currently my requirements are much less complicated than that as in i just want to share a common `consts py` file among different projects and I didn t want to use Stack References Do you think a similar approach makes sense

clever-painter-96148 · Answer

If you are sure you ll grow in complexity very quickly yes

clever-painter-96148 · Answer

But your question reminds me a former project where we somewhat overengineered a few stuff like we created a company constants package After 4 years only a handful of useful stuff landed in there but most of it was junk only used in a few places stuck out tongue

clever-painter-96148 · Answer

lesson learnt avoid that kind of packages as long as possible

clever-painter-96148 · Answer

that said this specific case was painful because it was in a multirepo environment in a monorepo environment i would be less afraid as refactoring is always easier

millions-pharmacist-626 · Answer

i don t think it s gonna grow that much more at best it s gonna get an extra project but in itself it s relatively small For info it s a repo to deploy a bastion server on AWS EC2 the 2 pulumi projects are the infra itself the IAM policies to manage the infra The 3rd project would have the codepipeline IaC Basically what I did is enable the management of this project through CI CD so that I can use a single pulumi account and everything is done through git commits and pull requests the CI triggers on merge to main

millions-pharmacist-626 · Answer

so basically if you were to git clone the repo today and get started with it you d do `cd pipeline` and `pulumi up` `cd iam` and `pulumi up` make any changes to `infra` and `git commit` + `git push`

millions-pharmacist-626 · Answer

im thinking of sharing it soon here when it s fully polished so if u care I can send u the link once it s public

clever-painter-96148 · Answer

I believe that well documented Pulumi based OSS projects are always welcomed and useful I found help thanks to such repositories many many times smile

millions-pharmacist-626 · Answer

ah yeah i also need to write docs ehehe

millions-pharmacist-626 · Answer

alright thx for the help slightly smiling face

clever-painter-96148 · Answer

Happy to help slightly smiling face