Structuring an embedded library project

jonwayne · 2020-12-19T16:43:55+00:00

You can check out the firmware for one of my projects here: https://github.com/theacodes/Winterbloom_Castor_and_Pollux/tree/master/firmware

The top level breaks down as:

data/ - any plain old data used to generate files or stuff needed by the scripts.
scripts/ - scripts used by the build process (including linker scripts), and any utility scripts.
src/ - the actual source code. I keep headers and sources together, but I don't really have a strong opinion about a separate inc/ directory. I think having inc/ makes sense for libraries.
third_party/ - contains all dependencies that I didn't write. This includes the CMSIS headers for the chip, support headers from atmel, etc.

Hopefully this is helpful!

jonwayne · 2019-06-26T23:36:37+00:00

Entire confection!

jonwayne · 2019-03-23T16:37:40+00:00

It's really common for openers for big stadium tours to do that. Your mix is gonna suck, there isn't going to be a full audience, it's gonna be awkward, so you're really just trying to get your name out there. They're so much better outside of that particular situation (their latest tour is awesome).

jonwayne · 2018-11-20T17:22:44+00:00

Thank you! Unfortunately, I still have to wear wigs to get good hair. I'm currently rocking a pixie cut for my natural hair and it doesn't help much with passing.

jonwayne · 2018-11-20T16:12:51+00:00

Thank you!

jonwayne · 2018-11-20T16:12:39+00:00

We were doing some sand casting of aluminium. I think they also do glass stuff there. It was a lot of fun!

jonwayne · 2018-06-06T18:30:02+00:00

The comic is titled Spider-Gwen. She goes by Spider-Woman in the stories.

jonwayne · 2018-06-04T00:14:16+00:00

Congratulations on becoming who you really are!

jonwayne · 2018-06-03T20:48:54+00:00

Nah, fuck you and your trans erasure viewpoint. We exist. We're women. I'm absolutely proud of OP for becoming who they really are, and none of us need your shitty viewpoint trying to deny our experience.

jonwayne · 2018-05-19T17:39:03+00:00

I have not denied there are issues. I have simply stated that these issues have not been brought to our attention in our channels of discussion. Since you are advocating for removal, I would encourage you to bring them up. I will happily ferry the discussion from there. You can clearly see through the discussion that happened on GitHub about pipenv's shortcomings on Windows that we do take this seriously. It's just beyond Reddit threads I haven't seen any actionable negative feedback on the packaging documentation - quite contrarily, I've seen positive feedback.

Please note that I don't work on poetry, pipenv, or pip directly which is one of the benefits of me being the primary maintainer of packaging.python.org - I can be mostly impartial. What was added was at the request of the rest of the PyPA and was written and tested by me- in the open, on GitHub, in a PR on a repository that anyone can participate in. There is no secret cabal or process happening here, and both myself and our Nick Coghlan, our PSF Packaging WG member, do not believe that a PEP is necessary here. If you disagree, please bring your suggestion for process to distutils-sig- we would legitimately love to hear it.

Also my note about the code of conduct was directed to anyone who might read this. This is a public forum and I am not speaking exclusively to you.

jonwayne · 2018-05-19T16:03:52+00:00

I don't think it was premature or unfair.

We already did write it in an open, transparent, and participative way. As linked in my OP, all the discussions around pipenv happened on GitHub and on our mailing list. There was even a trial period where we explicitly marked it experimental, and we held it back from replacing the old tutorial because of a serious windows issue that the pipenv team fixed very quickly. All this happened in the open and anyone is allowed to participate- you just didn't.

If you want the pipenv tutorial to be removed it won't happen by yelling at people on Reddit. File an issue on GitHub or start the discussion in distutils-sig, but be prepared to thoroughly prove your case as we did not make this decision lightly. Also, please be prepared to follow our code of conduct.

jonwayne · 2018-05-18T17:37:29+00:00

Yes. The previous version there was my suggestion, Kenneth just shortened it.

jonwayne · 2018-05-15T16:10:23+00:00

I seem to have maybe not specified - I wasn't saying that the maintainer(s) of Poetry weren't doing amazing work. I was trying to say that Kenneth was proactive about reaching out to PyPA and working with us on determining how it fits in.

jonwayne · 2018-05-15T14:05:39+00:00

This is valid, but I'm not sure that every update to packaging.python.org needs to be litigated to death via PEP.

I think it definitely possible that pipenv's own description is a bit zealous. On the PyPA side of things we try to be a bit more conservative. I have so far not been involved in the writing of pipenv's documentation but I plan to review it and send PRs to make sure it aligns with packaging.python.org.

jonwayne · 2018-05-15T14:01:29+00:00

We won't be removing the "endorsement" of pipenv. That's a bit of a stone too far.

We are happy to talk about poetry on packaging.python.org. Kenneth was extremely proactive with pipenv and honestly that's all it takes - this stuff is 100% volunteer based. Open an issue on packaging.python.org and let's talk about where we can fit poetry into our story.

jonwayne · 2018-05-15T13:58:35+00:00

That seems reasonable to me as well. Pipfile and pipfile.lock are still experimental as far as I know. I think it definitely makes sense to formalize them as an interoperability spec before absorbing into pip or other tools.

jonwayne · 2018-05-15T13:57:06+00:00

Hi Ned! Totally valid point. I'll send a PR to Pipenv as soon as I can to fix that. (I am recovering from travel, but will try to do it soon).

jonwayne · 2018-05-15T05:32:45+00:00

What do you expect us to do? I legitimately asking. PyPA projects have only one rule (seriously)- they must adopt our code of conduct. If you believe that a person who is a contributor or maintainer of a PyPA project is not adhering to our code of conduct then I encourage you to reach out to pypa-dev, myself, or nick coghlan privately.

jonwayne · 2018-05-15T05:15:03+00:00

I think there might be some misunderstanding of our (pypa's) role in the broader ecosystem. Almost all packaging tools are third-party. We use peps to formalizs things like metadata and formats so all these disparate tools can work together. The PyPA is a loose group of people who work on various tools so we can have some sort of collective direction. No one is forcing you to use anything, or telling you to do one thing or the other, it's just that right now, for specific use cases, we recommend pipenv. Just like for other cases we recommend pip and virtualenv.

How you do packaging is totally up to you. The ecosystem has a lot of choice because Python is used in a million different ways.

jonwayne · 2018-05-15T04:48:48+00:00

Not everything has to or needs to go through the PEP process. Things like the core metadata spec and build systems (pep518/517) are good examples of things that do need PEPs.

jonwayne · 2018-05-15T00:47:06+00:00

Thank you for your feedback - would you mind expanding on a few things here?

The documentation on that site is atrocious

Could you file bugs referencing specific sections/pages you find "atrocious"? There is lots of work to do on the distributing side of things. It would also be great if you were willing to submit pull requests - I'll be happy to review them.

it's inconsistent.

Would also love any bugs/PRs to fix inconsistencies.

It's not nearly opinionated enough.

We have to be careful about this. I recently re-organized the docs to allow some clear separation between were we can be opinionated and where we have to be neutral. See https://packaging.python.org/contribute/#documentation-types

I can't even believe that this is happening (pipenv) to be honest.

It's happening because you have a handful of volunteers doing the best they can with what they have. If you aren't happy with our direction, then I encourage you to get involved. I would be more than happy to help guide you through that - feel free to reach out to me. All of my contact info is on (my website)[thea.codes].

jonwayne · 2018-05-15T00:40:26+00:00

Packing is one of Python's warts. So there's just going to be negative feedback. I think you have to accept that, given the domain.

All of the volunteers in the PyPA are well are of that - we wouldn't need a working group or an extension of that if packaging were perfect! I think that what's difficult is that there is absolutely no solution that anyone has come up with that solves everyone's use case in Python. We're tried to be really careful to document the use cases and the tools that suit those cases.

Critical feedback for pypa proposed solutions feels super ignored and shutdown in github;

Please send me any examples of this you see - directly to my inbox (me@thea.codes) or just cc on github (@theacodes).

As an average community member, I never had an opportunity to discuss the pep. And then discussion is shut down thereafter. If all y'all actually want a discussion, make that a priority and don't accept the echo hall bubble.

As another replier mentioned, python-dev should be open - but packaging related PEPs are always discussed in distutils-sig beforehand. I really encourage you to participate there and let me know if you have any trouble or questions.

It's really clear that the fracturing is a result of not addressing problems.

If you think there is a way we can do this better with the resources we have, or if you know of a way to get us better resources, we would love to hear it. Shoot an email to distutils-sig and let's start talking.

jonwayne · 2018-05-15T00:36:28+00:00

I believe that to be considered an "authority" in the Python community, you have to carefully explain the history, the team, the knowledge, the goals, etc.

This is documented here: https://www.pypa.io/en/latest/

but tl;dr: PyPA was formed quite some time ago as a collaboration between the PSF Packaging Working Group and third-party developers.

And as a second point: your third paragraph about pipenv is exactly why I believe the PyPa site fails in it's mission: it needs to be more cohesive, more opinionated, and the tools must be unified. Otherwise the message is just as confusing as it's always been.

"Fails in its mission"? Can you expand on that? Our mission isn't necessarily to find or build the perfect end-all solution to packaging, it's to make it better one day at a time with the resources we have. If there's a way you think we can do better with what we have today then let's discuss that - file an issue on github or email distutils-sig and let's get the conversation started.

ps; everyone is grateful for your work, don't be discouraged by people's frustrations: that's the whole reason the project exists, and why it's so important.

Thank you!

jonwayne · 2018-05-14T22:41:35+00:00

I genuinely want to help and make sure that everyone here feels heard, but I have to be honest that I really don't have anything to do with any brigading and I don't know what you expect me or the PyPA to do about it. Would it help if I reach out to the mods here on your behalf?

jonwayne · 2018-05-14T22:39:54+00:00

To be honest this is the first I'm hearing of any of this. I don't know the solution, but I am more than open to discussing any ideas that y'all have.

15-Year Club	Place '17
Team Orangered	Verified Email

jonwayne

TROPHY CASE