Comments (7)
This begs the question of whether we should bring back the --target
option to mix nerves.new
so that this one dependency could be generated for the system they intend to use. In that case, would we simply depend on version >= 0.0.0
?
from nerves.
I prefer not having --target
flag. or make it optional at least.
We could have tooling for adding a system.
mix nerves.new blinky
mix nerves.system add "nerves_system_rpi3"
from nerves.
I'm not sure about nerves.system add
since that feels like the user should be able to run it after they've substantially edited their mix.exs, and then we'd have to be careful about editing their existing deps.
Fwiw, I never had bad feelings towards the --target
option on nerves.new
. It seemed like a nice convenience for getting started. If it's optional, it would be nice to have a comment with what to fill in for the deps (maybe assume nerves_system_rpi3?) so that if people forget to run it, they can just uncomment some lines and go. Would that be ok?
from nerves.
I think it's reasonable for it to be optional and just default to putting the rpi3
dep in there by default.
Then again, we could just generate a list of all the popular options so the option is still not needed and it's easy to delete or ignore the ones you don't plan to use. The problem remains that we won't know what version of the system dep to include based on the --target
option, so at least if they're all there, we can maintain a sane version baseline with each release of nerves_bootstrap
.
from nerves.
I don't understand your comment on versions. If we're going to generate a nerves system dependency with nerves.new, we have to specify a version, but we do that now. I don't think this change makes versioning any worse in that regard.
from nerves.
We currently assume all the systems are (approximately) version 0.11.0
. I thought part of the intent of this change was to decouple the versioning of the systems from one another, so that we don't have to assume that's the case.
If someone says --target rpi3
vs. --target ev3
, we would need to know what version to generate for that dep, unless we just assume that >= 0.0.0
is good enough for all of them and people can choose a specific version if they want to.
from nerves.
Got it. That assumption that all systems are approximately version 0.11.0
is wrong. For the longest time, the BBB was a version ahead of the other systems. Now the alix, galileo, and ag150 systems are pretty far behind. The constraint to keep all systems roughly the same version is really hard to maintain. I have tried to keep versions the same since I do frequently do directory comparisons between systems to catch differences stylistic and other deltas. However, if I had appreciated the assumption that system version numbers had to be changed together, I would have pushed back sooner.
>= 0.0.0
isn't really right, but I don't have any better suggestions and I still like the idea that the system is automatically added in nerves.new.
from nerves.
Related Issues (20)
- Fix JSON handling HOT 1
- Broken packages in Nix-shell file HOT 3
- firmware.patch should handle FAT resources delta updates
- minor issues with FAQ.md HOT 3
- Help Mod bus, TCP/IP HOT 1
- Hardcoded check for GNU Coreutils on MacOS HOT 3
- Elixir 1.15 / OTP 26 support
- `mix firmware` failure during squashfs HOT 9
- Provide more helpful script output with `mix firmware` task errors
- Contributing link in readme is broken
- Formatting in installation instructions are unclear HOT 1
- Failure entering the nerves.system.shell using erlang 26.0.2 HOT 2
- Update Dependabot settings and CI auto merge
- nerves.system.shell information out of order HOT 1
- Documentation outline improvements
- Running `mix compile.nerves_package` crashes HOT 3
- Broken links in hex documentation HOT 1
- Discourage mktemp usage HOT 1
- Load Nerves.Runtime.KV in runtime.exs crashes system HOT 3
- Unhelpful error message disk does not have enough space to extract artifact
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 nerves.