We have had a solution for this built into Codex for several months now. It is marked "Beta" in the docs because we have been tweaking the config API here and there, but a number of folks have been using it for quite awhile and I would recommend switching to it and reporting any issues you find:
- Mark a path, glob, or meta variable (like `:workspace_roots`) readable, writable, or unreadable.
- Amend an existing profile using ordinary `config.toml` layering rules.
- Create a new profile by extending an existing one (`extends = ":workspace"` is generally what you want to do).
Note that permission profiles also allow you to configure the network proxy for the sandbox in a fine-grained way. (Previously, the network options for the Codex sandbox were all or nothing.)
Finally, you can also test running a command under a permission profile using:
codex sandbox -P PROFILE_NAME -- PROGRAM ARGS...
Our goal has been to provide something powerful and flexible out of the box so you do not need to bolt on other solutions like the ones mentioned on this thread.
DotSlash is a new, open source command line tool that makes large executables available in source control with a negligible impact on repository size, thus avoiding expensive clone operations.
Originally started as an extension to Mercurial, but grew into its own SCM with a cross-platform virtual filesystem in C++ and a distributed server in Rust.
> Despite having originally evolved from Mercurial, EdenSCM is not a distributed source control system.
i.e., this is not "stock" Mercurial. For example, the Eden server (Mononoke) is written in Rust and the complementary virtual filesystem is written in C++. This has very different performance characteristics than real Mercurial.
EdenSCM works with both EdenFS (the custom filesystem) and a traditional filesystem. If you use EdenFS, pulls will be much cheaper because you only fetch what you use. If you use a traditional filesystem, EdenSCM supports the same "sparse checkouts" feature as stock Mercurial (https://firefox-source-docs.mozilla.org/build/buildsystem/sp...), which can also be used to reduce the size of the slice of the monorepo you pull down.
Last I checked, Perforce (and Google's "implementation" of Perforce, Piper) did not provide nearly the same level of support for stacked diffs as Eden. As both Google and Facebook have cultures of pre-commit code review, working with stacked diffs makes it much easier to make progress while waiting for approvals on earlier diffs.
I believe there are relative advantages/disadvantages of Eden vs. Piper+CitC and that both projects aspire to have the best of each in the limit.
When I started the project, Buck had one specific goal: to make Android builds faster (https://youtu.be/CdNw6mRpsDI). At the time, the recommended way of building Android (from Google) was to use Ant. So when someone points to Buck as an example of "creating competing tools more often than persisting with and improving existing ones," I'd like to point out that you can't fix Ant if these are your issues with Ant:
* It is unsound.
* Because it is unsound, it is irreparably slow.
* It uses XML as a build language.
Yes, in July 2012, there were a number build systems on the market (though Bazel was not one of them, but Pants was), and none of them focused on building Android. And even if they did, few (if any) software companies were building an Android app as large as Facebook, so it was unlikely that anyone else was going to design for our scale.
It also wasn't just about build times, but about how I wanted to see us organize code in our repository. At the time, there was a flat list of folders in the Android repo, each called lib-something. This drives me insane because you inevitably end up with two (or more!) people creating com.facebook.common.StringUtils, each in their own lib-something. (It's also annoying to `ls` this "lib-" directory over time.)
In contrast, Buck/Bazel encourage the use of a unified tree, but still encourage fine-grained modularization (which is key as your build graph gets very large). This has been shown to scale to extremely large monorepos at both Facebook and Google.
Finally, by having total control of the build system, we were able to build in all sorts of cool tricks to build Android very fast, both in the large and in the small: https://youtu.be/Y9MfGS3qfoM. I don't think there is any other build system we could have decided to work with at the time to achieve these gains.
Buck has since evolved to build everything else at Facebook. This is not because the Buck team set out to conquer the world, but because people internally wanted the benefits of Buck for their builds. Building an alternative toolchain to xcodebuild was a mammoth effort (and one for which I take no credit). Having one build language for a heterogeneous collection of programming languages in a monorepo is no small feat.
Finally, to the people who believe "The big guys want developers locked into their ecosystems," I have news for you: the Buck team is not offended if you use Bazel, Gradle, Make, or anything else. Buck is open source because we wanted to share it with the community, not dominate it. Like many of you, people are excited to show their work and learn from others.
(1) Atom wants to support a world in which every Atom package can install whatever version of a dependency it wants, including React. This is very common in Node (incidentally, this causes problems if you want to use singletons or instanceof in Node), but fairly uncommon on the Web (where React is primarily used). That is, it's rare that you inadvertently load multiple versions of React in your single-page application. If you did, you would likely get an error when adding one React component as a child of another React component because of the way React vends ids. (Solutions are possible, but none is employed today.)
From Atom's perspective, that is a problem. The only way they can work around it is by providing "one true version of React" with Atom core that all packages must use, but then Atom is forcing all packages to use a particular version of React. That would violate Atom's philosophy of letting each package choose its own dependencies.
(2) This is not just an issue for React, but for any UI toolkit whose components are not guaranteed to interoperate across versions. To sidestep this issue, Atom has currently decided to use the DOM API/HTML custom elements. I would call this the "least common denominator approach," which satisfies Atom's design goals, but fails to provide a higher-level abstraction for building UI in Atom. It's a tradeoff.
(3) React does not currently support the shadow DOM or custom attributes, which is the new direction that Atom has chosen. As React has not yet been evicted from Atom core, I recently upstreamed a change (https://github.com/atom/react/pull/1) to add one-off support for Atom's primary custom elements, <atom-text-editor mini> and <atom-panel>, in the fork of React bundled with Atom. As I develop Atom packages using babel (formerly 6to5) http://blog.atom.io/2015/02/04/built-in-6to5.html, which has default support for JSX, building UI in React has been a lot of fun. However, the lack of support for custom attributes makes it difficult to do things like add an appropriate onChange handler to an <atom-text-editor> to update the React component's state as shown in http://facebook.github.io/react/docs/forms.html.
(4) React is still version 0.x.x, which means it has not yet committed to a stable API. This makes choosing a version of React to bundle with Atom an even more uncomfortable decision for the Atom team, assuming they were willing to do so in the first place.
None of these items implies that there is something fundamentally broken about React's model. It just means that the React team has some work to do in order to support Atom's use case. The performance graphs cited in the original post are also significant (and of interest to the React team), but even if the performance problems were fixed tomorrow, that alone would probably not be enough for Atom to pull React back into core right now.
https://developers.openai.com/codex/permissions
With permission profiles in Codex, you can:
- Mark a path, glob, or meta variable (like `:workspace_roots`) readable, writable, or unreadable. - Amend an existing profile using ordinary `config.toml` layering rules. - Create a new profile by extending an existing one (`extends = ":workspace"` is generally what you want to do).
Note that permission profiles also allow you to configure the network proxy for the sandbox in a fine-grained way. (Previously, the network options for the Codex sandbox were all or nothing.)
Finally, you can also test running a command under a permission profile using:
codex sandbox -P PROFILE_NAME -- PROGRAM ARGS...
Our goal has been to provide something powerful and flexible out of the box so you do not need to bolt on other solutions like the ones mentioned on this thread.