101–110 of 118 posts
I saw this Twitter thread the other day ( https://twitter.com/fchollet/status/1617704787235176449?s=46... ) about similar problems, and some comments suggest using Docker. I couldn’t find any guides or ways to do this for a Python project; anyone here know more or has done this before?
Earlier quoted context omitted.
npm has the same property of keeping the files locally, but without any need to activate/deactivate a venv. It “just works” that way by default if you “npm install”
Once you create a venv, you can just refer to its path. I always disliked the whole activate/deactivate steps.
Earlier quoted context omitted.
At least with Lambda it really is easy, just use Serverless Application Model and when you do “sam build” choose “--use-container”. It will look at your CloudFormation template where you are referring to the local directory containing your source code and requirements.txt and download and build in the appropriate Docker container for your language, version and architecture. It works great when you have native depende…
I assume that means container based Lambdas, which would have slower cold start times and maybe some other disadvantages, but yes, it would be simpler.
In your CFT you specify the local directory and the architecture.
SAM will download the Amazon Linux container for your language runtime locally using the correct architecture (x86 or ARM) and download the correct dependencies based on your architecture and package everything in a local folder. It will then output a modified template pointing to the local folder where your Lambda was built. It will contain your source code and dependencies that are compatible with Amazon Linux.
“sam package” will then zip the files up built by Sam build and upload them to S3. It will then create another template that references the zip file in S3.
“Sam deploy” will deploy the standard zip file based Lambda.
This lets you build zip file based Lambdas locally including Amazon Linux native dependencies on either Windows, Macs or other versions of Linux.
Earlier quoted context omitted.
> I revoked sudo privs immediately for Jenkins (I didn't add them in the first place) If you allowed sudo in your jenkins jobs you're morally barred from blaming python for screwing up the system.
The problem here started right at the hiring manager.
> There’s no shortage of package management alternatives available for Python [...] > How someone is meant to pick between these as a new developer is a mystery. This. Every time I get booked to look at some Python project hours are usually wasted initially figuring out what dependency mgmt solution was used how. And with what 'special sauce' the resp. developers deemed to be 'the right way' (or some library required…
python3 includes "venv". If you don't have an existing preference, use that. python3 -m venv ../my-venv-dir # wherever you like . ../my-venv-dir/bin/activate pip install whatever you can close your terminal and "rm -r" the venv dir, and no trace will be left. (or you can just "deactivate" and use it again later)
I'm not sure if I get the point of this article. So basically the author has learnt that there are a different ways of managing packages in Python? I'm aware that this might be a problem in Python, but let's be serious guys, you only need to spend 5 mins to learn about venv/conda and you will never face any problem in a basic Python project. You don't have to write an article about that.
As an outsider, the ecosystem looks like a mess. The point of the article is to illustrate some of those issues.
It's entirely reasonable for people to have problems when using it.
Earlier quoted context omitted.
I assume that means container based Lambdas, which would have slower cold start times and maybe some other disadvantages, but yes, it would be simpler.
No. You just build zip file based Lambdas locally using containers. In your CFT you specify the local directory and the architecture. SAM will download the Amazon Linux container for your language runtime locally using the correct architecture (x86 or ARM) and download the correct dependencies based on your architecture and package everything in a local folder. It will then output a modified template pointing to the…
The next Debian/Ubuntu releases will no longer allow `pip install` outside of a venv: https://discuss.python.org/t/pep-668-marking-python-base-env... You can still force it via `pip install --break-system-packages ...` if needed.
For anyone on other systems who wants this kind of protection right now, pip has had this available for a few years at least:
pip config set global.require-virtualenv True
The article talks about installing Python packages for development, but if you find yourself using `pip` to install Python tools/scripts then you should use `pipx` - it will properly sandbox those tools so they don't break (or be broken by) the system or other Pythons: https://pypa.github.io/pipx/