Comments (7)
What is the use case that should work on all UNIX variants except Linux and macOS in a recipe?
from just.
What is the use case that should work on all UNIX variants except Linux and macOS in a recipe?
I don't have such a use case. I don't care about excluding Linux; I care about excluding macOS.
Currently, there's no way to write a recipe for "all Unixes except macOS". I can write a macOS recipe, and a Linux recipe; but there's no way to write one for Free/Net/OpenBSD (or, I presume, Solaris or any other platforms — I have no idea how many are theoretically supported).
So if I have platform-specific tasks, where things are done one way on macOS and a different way on other Unixes, I can't use the attribute system to implement that. What I think should work is something like:
default: platform
[macos]
platform:
# macOS specific here
[not-macos]
platform:
# other-platform-specific here
Or:
[linux,freebsd,openbsd]
platform:
# listing all the platforms would also be fine
from just.
I'm not the developer but I believe it would very likely help to have a use case to justify the dev time and ensure there is an overall benefit to the community. I like the idea of having the more granular options (dragonfly, freebsd, netbsd, solaris, etc.) but I can't think of a reason where it would be specifically beneficial. I just happen to like the idea of it. All Unixes follow the POSIX standard pretty close so a programatic reason to treat any of them differently would be enlightening.
from just.
I'm not suggesting treating them differently. I'm suggesting making it possible to indicate them in a way that makes use of the existing feature.
The issue is that there's an asymmetry in the current OS attributes. There's unix
and windows
, which obviously do not overlap. Then there's linux
and macos
, which are both treated as subsets of unix
. But then there are some OSes which are unix
but not linux
and not macos
. What this means is that if you want to use linux
or macos
attributes and another unix
that doesn't have a more specific attribute, there's no way to make this distinction.
I'd happily try writing a pull request for this myself, but I'd like to make sure that the developer is interested in such a change before doing so.
from just.
Sorry for letting this sit! This seems like a totally reasonable feature. I'm not sure if we should implement this in a more general way, e.g., allowing inverting attributes. Or, if we should implement it in a narrow way, e.g., an attribute which is true on non-macos unixes.
from just.
I prefer the narrow way but I don't see how you can do that with any rationality. If I remember correctly, Darwin is a fork of FreeBSD UNIX. It seems to have over 80% of the BSD UNIX spec if not the entire POSIX spec. A bsdunix
and unix
should both legitimately include macos
. I can think of no rational to separate it out from those two categories. Now if we name each exact distribution, that could work. But then if I (for some unlikely reason) want to include all the UNIXes except macOS as the one exclusion the list is going to be pretty long.
The one rational in my mind for separating macOS from the other UNI is that it doesn't come with X Window installed by default. As do "server" versions of many distributions. So, have an x-window tag that checks if X Window is installed on the current OS makes way more sense to me than arbitrarily trying to exclude macos
. But if you're going to do it no-macos
is the only rational way to handle that situation in my opinion. Listing out 10+ other UNIX distros just to include all UNI except macos
just doesn't make any sense to me.
from just.
If I remember correctly, Darwin is a fork of FreeBSD UNIX. It seems to have over 80% of the BSD UNIX spec if not the entire POSIX spec.
Yes, as I mentioned in my initial post. It's difficult to find a meaningful name for the grouping of unix && !macos
(or unix && !macos && !linux
).
I could see an argument for simply having an attribute tag for every supported platform, but this could easily become impractical since I think the Attribute
enum would need to contain a complete list of those, as well as having the correct logic in the enabled
method.
And actually, I think that in order to implement this, enabled
would either need to check for target_os = freebsd || netbsd || openbsd || dragonfly
, or otherwise it would boil down to being unix && !macos
after all. The latter probably scales better, but that still leaves the question of the name.
The one rational in my mind for separating macOS from the other UNI
The rationale is that its behaviour and configuration is significantly different from other Unixes. Although it is, strictly speaking, a descendent of BSD Unix, the others are all far more similar to each other in a lot of ways than macOS is.
So, have an x-window tag that checks if X Window is installed on the current OS makes way more sense to me than arbitrarily trying to exclude macOS.
I don't think this could make sense. Many Unix machines do not include X11, because X11 is not usually installed on servers either. (And Wayland might mean that an increasing number of desktops/laptops do not have X11 installed either.) It certainly wouldn't have solved my original specific usecase, though it might be something that other people would find useful.
from just.
Related Issues (20)
- Add a --list-paths to output list of recipe paths only HOT 4
- Submodules should be groupable (or have their own group) HOT 6
- Passing arguments for python different than node? I needed to add -- HOT 4
- Parser support for attributes with multiple arguments HOT 1
- Module improvement tracking issue HOT 2
- No .ps1 extension added when pwsh.exe is started via third-party tool HOT 6
- Possible to get autocompletions working in Warp?
- dotenv-path unexpectedly loads .env from parent directory HOT 1
- [Feature Request] `just global init-rust`; an ability to define global `Justfile` that will run commands anywhere on your machine. HOT 2
- Stabilize `[script(…)]` attribute HOT 6
- Comments Ending in Backslash also Comment following Command HOT 2
- Add ability to add new dependency without clobbering rule HOT 6
- Transitive options when using modules
- `just --list` should highlight parts of the comment surrounded by backticks (`) HOT 1
- Set default working dir for the whole justfile HOT 2
- Multiple optional parameters, specifying only one HOT 1
- Command line flag to exit without error if recipe not found HOT 1
- Add missing or (if it's there) improve module information in documentation HOT 1
- Mark recipes as exportable/non-exportable HOT 1
- Warning when compiling with Rust 1.80 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from just.