The event is on November 9-10. Submissions close August 31. It looks like a great opportunity to present fpm.
See http://packaging-con.org/ for more info.
9 Likes
Any thoughts on what aspect of fpm we would discuss. The topics seem interested in the technical details and possible general application to other projects. We’ve drawn inspiration from other package managers, but I don’t know if there’s something new that fpm brings to the area. Maybe the complexities of detecting the dependencies for compilation order in Fortran?
1 Like
Right, I don’t think it needs to be super novel in the computer science sense. Here are some ideas:
- Fortran-specific package manager and build system is interesting in and of itself.
- That it’s implemented in Fortran is interesting too. This will be a good showcase for Fortran itself as well.
- Fpm’s technical challenges and how we are (or plan to be) solving them, e.g.:
- Module dependencies and avoiding name clashes
- How fpm handles fpm-aware dependencies
- External modules (fpm-unaware dependencies)
- Building mixed-language packages and dependencies
- Plugins
- How do we plan to grow the ecosystem?
3 Likes
This looks really interesting, thanks for finding it. Seems like the organization is done by a lot of folk active in the conda ecosystem.
Fortran itself has interesting aspects when packaging it (binary rather than source packaging), like ABI compatibility between versions when linking dynamically or the distribution of module files when working with several compilers. Especially the ABI issues can be a nightmare when packaging Fortran projects, either the version pinning has to be very tight or one links statically with all the drawbacks of rebuilding, bloated artifacts and the license distribution. One the other hand, some Fortran projects have incredible stable APIs over decades, like LAPACK.
1 Like
I’ve been part of some of the organizing calls for PackagingCon, but didn’t have time to be more involved. Yes, we definitely have to present fpm. More importantly, the goal, as I personally see it for the conference (and that I presented on some of the calls, and other organizers didn’t seem to disagree), is:
- Talk to other package managers, see what problems they are solving
- See if there are ways to collaborate
- Perhaps even actually collaborate on some things, from brainstorming designs (perhaps what metadata the package manager should store) to more tight collaboration, we want to be able to call Conda and Spack from fpm to install depencencies and vice versa. The Julia package manager is also calling Conda (or was), so they have the same issue.
I am sure the organizers have some other goals, but if the above happens, I would consider it a success.
With this in mind, we can submit a talk.
4 Likes
Just got the confirmation that our abstract is accepted.
8 Likes
The list of talks is up now: PackagingCon 2021 - a conference for package manager developers and packagers
4 Likes
Note that registration is not free:
For this reason, we have chosen to sell tickets with a pay-what-you-can pricing model.
Suggested prices
Student/Academic: $20
Professional: $50
Professional, reimbursed by employer: $100
3 Likes
The lightning talks of the first day of PackagingCon are currently running.
My personal highlight today was certainly Todd Gamblin’s talk about spack’s concretizer and answer set programming (not sure if the link to the stream will work): Room 2 Day 1 - YouTube
4 Likes
Day 2 of PackagingCon just started with a deep dive into a couple of package ecosystems. I’ll be talking about fpm and our Fortran community at 6:20 pm (UTC), feel free to drop in at Room 2, Day 2 - YouTube.
3 Likes
Exciting times, congrats and good luck @awvwgk, I look forward to the fpm talk especially, among others.
3 Likes
I listened to your talk @awvwgk, you’ve done a great job, you hit all the main points and answered all the questions well. Thank you for giving the talk and preparing it. The slides also l looked very nice and polished. Nice pictures.
We should brainstorm how to integrate with other package managers, that’s been on our TODO from the very beginning. Spack now works on Windows, so I think both Spack and Conda are good candidates, both provide a uniform cross platform packages. It seems a good option is to support both (and in the future any other package manager if some come along).
First I would worry about non-Fortran dependencies. We can worry about mixed Fortran/C++ dependencies later, one option there is to use fpm for the Fortran part.
It seems one way is to allow to specify a non Fortran dependency in fpm, say the LLVM package, as an “llvm” and then describe how to install LLVM using both Spack and Conda (and others, such as apt-get). You would specify as much as you can regarding the exact version, etc. Then fpm would choose the one you prefer, some users might prefer conda, some users spack, etc.
3 Likes
For newcomers to fpm, and for myself, what exactly do you mean by “integrate with other package managers”?
Is it:
- Allow fpm to use a Spack or conda package as a dependency in an fpm project?
- Allow fpm to output (generate) a Spack or Conda package definition for an fpm package so that Spack or Conda can use it?
- Both of the above?
- Or something else?
If more than one, what do you think is the highest priority? It seems to me that 1 would have the biggest bang for the buck, and 2 comes close in importance.
It was a great talk, @awvwgk, thank you for doing it!
2 Likes
In the above comment I was talking about 1.
I know Todd from Spack is interested in 2., or to figure out how spack can use fpm packages naturally. But I would worry about 2. later, let’s first figure out 1.
3 Likes
