netfarm VS pip

/u/read-eval-print-loop and I wrote GitLab CI testing configs, though I don't know how much relates to Jenkins. The general recipe is that one starts with an environment with SBCL (and Clozure and any other implementations you want to test on), clones in extra libraries if necessary, and then loads a short file which then loads the test suite, runs it, and exits with an appropriate status code, which the CI (presumably Jenkins too?) uses to produce a status to report.

Tests for the Netfarm suite and Minecraft mostly.

I threw TLA+ at a few fine-grained locking algorithms I wrote. Here is one such model. The actual implementation is more complex than the model, in particular because the real implementation of this code handles multiple concurrent resource requests, but they are "independent" enough that I can probably just prove a model with just one resource; and, as Lamport said once, the model code doesn't have to be particuarly well optimized, whereas if you are breaking locks, you probably have substantially optimized already.

I work on a metacircular Common Lisp implementation, which makes for a very boring answer. In the next closest thing to a job, I use CL for just about the whole network stack, so really anything would be suitable. But I wouldn't dare throwing a new language into a workplace, and I am not sure how much they would appreciate it.

One very niche "counter-example" is a system where loading files causes side effects, which must occur in some order. This happens in the Netfarm object system implementation, where most of the bootstrapping steps occur in an early system definition and a late system definition. In this case it is not enough to compute the dependency tree; it is necessary to pick a very specific ordering for things to not break.

Alexandria, yes, anaphora, not anymore. I do have a fairly large utility package for decentralise2, but it mainly handles concurrency and debugging things.

If it's not distributed under the Cooperative Software License, I don't want it dirtying up my CPU.

Whenever you are working on a Python project that has external dependencies installed with pip, it is strongly recommended to first create a virtual environment.

Unfortunately that feature is easy to break: https://github.com/pypa/pip/issues/9644

I think I did my part https://github.com/pypa/pip/issues/6409

$ sudo pip install y$ sudo pip install yaml WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip. Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue. To avoid this problem you can invoke Python with '-m pip' instead of running pip directly. ERROR: Could not find a version that satisfies the requirement yaml (from versions: none) ERROR: No matching distribution found for yaml

What are you implying will happen?

Using the build-in tools, you can save the exact versions of dependencies (i.e. a lock file) using "pip freeze >dependencies.txt". This should give you the exact same set of packages in two years' time.

If you want to be even more sure, you can also store hashes in the lock file. This has to be generated by a separate tools at the moment [1][2] but can be consumed by the built-in tools [3], so "pip install -r requirements.txt" is still all you need in two years' time.

[1] https://github.com/pypa/pip/issues/4732

[2] https://pip-tools.readthedocs.io/en/latest/#using-hashes

[3] https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

Here’s the issue, https://github.com/pypa/pip/issues/11664. I think the idea would be to have some file/json description of environment that could be passed to pip to allow it to fully cross compile. They are open to supporting it just needs contributor to be found to implement it and go through review/discussion.

To be fair the only alternative is fixing Python, and even then you still would have to wait a good 5 years at least for all the old Python versions to dwindle.

It doesn't look like the fixing effort is progressing very quickly: https://github.com/pypa/pip/issues/8606

To their credit, at least they didn't close it "works as intended" which I imagine a lot of projects would.

Another good benchmark to trying to resolve apache-airflow[all]==1.10.13 using the state of PyPi on 2020-12-02, I give instructions here on how to reproduce that workflow: https://github.com/pypa/pip/issues/11836. Including a benchmark how how many extra packages your resolver should visit.