15 ms·

PackagingCon – A conference only for software package management

189 points by droelf 3y ago

predictabl3 3y ago
Should've scheduled it in September. Folks could've popped in after NixCon ;).
- lillecarl 3y ago
  I don't quite get why we need PackagingCon when there's already NixCon ;)
- hobofan 3y ago
  It's directly after BazelCon which is held in Munich this year, and has some thematical overlap.
swyx 3y ago
oh i love ultra niche conferences like these. good luck and looking forward to it! looks like the CFP closed :/
- seabass-labrax 3y ago
  Unfortunate timing to be on HN - it only closed a couple of days ago. Out of interest, might you be able to share your paper/project here?
- cik 3y ago
  I emailed them because of that! Without it showing up here on HN, I'd never know it existed.
hashtag-til 3y ago
Surely the program will be packed.
- peoplearepeople 3y ago
  I'm pretty excited about it
- tough 3y ago
  I see what you did there, hasttag-til lmao
- bnchrch 3y ago
  Hopefully they have a good manager to keep things working and organized....
  - felipellrocha 3y ago
    When will the schedule be determined?
    - bnchrch 3y ago
      I hope I dont have any _conflicts_ in calendar
- layer8 3y ago
  You'd think so, but it's a con.
serial_dev 3y ago
At first, I thought it's a joke conference site, but if I think about it, it's actually a great idea! Just goes to show how we are (or at least, I am) used to $PROG_LANG conferences, or Agile/SysAdmin/SRE/Mobile confs. Could be cool to have linting conf, code editor summit, etc.
- pxc 3y ago
  Relatedly: there actually is a configuration languages conference out there! 2021: https://2021.splashcon.org/home/conflang-2021 https://2021.splashcon.org/home/conflang-2021 2023 (upcoming): https://2023.splashcon.org/home/conflang-2023 https://2023.splashcon.org/home/conflang-2023
ISV_Damocles 3y ago
Would be fun of them to get a keynote speech from someone involved with EPS[1] (no, not that EPS[2]). I do wonder what parallels the two kinds of packaging have in common. [1]: https://eps.ieee.org/ https://eps.ieee.org/ [2]: https://en.wikipedia.org/wiki/Encapsulated_PostScript https://en.wikipedia.org/wiki/Encapsulated_PostScript
- seabass-labrax 3y ago
  As an expert in the software kind of packaging but only casually knowledgable about the electronics kind, I suspect rather little. However, the former is probably going to be much more prominent in the microelectronics world soonish, as dynamically configurable chips based on FPGAs are becoming very popular, and highlight more than ever how inadequate the conventional IDEs and SDKs for embedded software are. Proper software packaging is almost non-existent in embedded software engineering, but the current work-around of just using one company's SDK for everything won't scale to support all the FPGA cores that people want to use.
bnchrch 3y ago
This might be the most mundane topic Ive found myself naturally extremely excited about. If your a developer working full time in only one or two languages you may never experience just how good/bad you have it. When you do, its really eye opening. Every time I transition to a new language professionally it can be like opening a bag of Bertie Bott's Every Flavor Beans when you look into the packaging story. * Go binary release story is great but the gopath method for dependencies is annoying * Elixir has lockfiles and built-in package docs but the release story deviates too much * Javascript now that everything has settled into npm is a delight but the lack of stdlib, painful local aliasing and extremely heavy node_modules folder can be offputting * Python just sucks (lets hope poetry can bring the promised land of deterministic builds)
- seabass-labrax 3y ago
  The Python world won't improve as long as programmers add dependencies on libraries written in other languages and (here's the important part) attempt to compile those packages themselves within a Python build process. Poetry is a nice chapter in the Python package definition story, but it is only a tentative step to fixing the wider problem.
- bluGill 3y ago
  I firmly believe that languages should not manage packages. While it makes the simple cases easy for beginners, the trade off is mixing languages becomes harder. There is no perfect language and often mixing should be the right answer and we don't want any more friction there.
  - seabass-labrax 3y ago
    I quite agree! And would it even be harder for beginners? When trying a new a program written in a language I don't use frequently, I usually spend a good half-hour working out what command to run to install the dependencies and going through the logs working out what implicit requirement wasn't in the README. A holistic package, even one written for a different software distribution than the one I use (Debian at present), would immediately get me 99% of the way there. PS. If you find yourself in the same situation I do, Repology is your friend: https://repology.org/ https://repology.org/
BigElephant 3y ago
naive question - doesn't docker 'solve' this?
- treve 3y ago
  The question is a bit short, so I'm inclined to say: no, the things they solve is only mildly related. But maybe you have a specific thing in mind that Docker solves, so feel free to share what you think so someone or me can say something more useful about this!
- orange-mentor 3y ago
  Not exactly. Most Docker containers rely on distro package managers. You're usually running apt or apk inside your Dockerfile. And the container system rootfs needs to be laid out. It's a non-trivial amount of work to do that and keep it up to date. I am a fan of building a traditional native package in a multi-step Docker build, and the final container artifact can be a simple `RUN deb -i my-pkg.deb` I find that targeting traditional system packages has benefits. 1) it's not really that hard, and 2) it forces you to lay things out consitently, or, at the very least, the distros conventions are helpful.
- alfalfasprout 3y ago
  NOPE. Docker neatly encapsulates the problem and allows you to somewhat ship a reproducible deployment... until something needs to be updated. Now either you rebuild your image (which may not be reproducible) or patch it (which comes with its own share of problems). Caching can also be a nightmare if your image is built from common stages. Dealing with vulnerabilities is also a pain especially for things already in production. Docker (or container images in general) are great but they solve a limited set of problems well and tend to hide others.
  - chriswarbo 3y ago
    > Docker (or container images in general) are great but they solve a limited set of problems well and tend to hide others. I like container images and runtimes. Docker is awful, and its "inside-out" approach encourages and enforces bad practices.
throwawaaarrgh 3y ago
I can't wait for ShoelacesCon. Last year I couldn't make it; I was all tied up.
benatkin 3y ago
I hope they consider this: https://github.com/deislabs/bindle/blob/main/docs/invoice-spec.md https://github.com/deislabs/bindle/blob/main/docs/invoice-sp... Bindle seems interesting but I'm not quite sure how to use it or whether it will take off anytime soon. Maybe cargo has some of its interesting features.
- seabass-labrax 3y ago
  I don't understand yet what Bindle is trying to do. It seems to be half archive format, half package manager, yet not innovating in either area nor adding anything by their combination. Additionally, it explicitly doesn't support 'latest' tags or branches, which exist in package ecosystems for a reason.
  - benatkin 3y ago
    It seems the client/server is neccesary. Not an issue for cloud projects composed of many servers and SDKs like Deis Labs or Fermyon, but an issue for others wanting to adopt it.
ary 3y ago
They have a YouTube channel and I hope they publish all of the talks after the fact. Should anyone from the conference read this it would be great if paid corporate packages were offered that made the recorded sessions available for download. https://www.youtube.com/@packagingcon9302 https://www.youtube.com/@packagingcon9302
binary132 3y ago
Unpopular opinion: old-style GOPATH semantics are significantly better than “package management”.
- seabass-labrax 3y ago
  It's not an unpopular opinion! Perhaps ironically, it is for the package management that software distributions provide (Debian, Fedora etc.) where GOPATH is most used - the Go modules system interferes with the guarantees that those distributions make about the builds, whereas GOPATH lets the distributions calculate dependencies themselves.
  - binary132 3y ago
    almost as if the designers knew what they were doing
0x0203 3y ago
I'm not going to say where and I'm not asking for interested parties (we're not currently hiring anyway), but where I work (as a kernel/OS developer), package maintenance and management has been an ever-increasing burden to the point that we've tried hiring somebody specifically for the role. Unfortunately, it seems like this is a very specialized skill set that the vast majority of developers seem to find boring, uninteresting, and drudgerous, and finding someone qualified and interested has been exceedingly difficult. How would someone/a company go about finding people that are actually interested in this kind of work? There are clearly people who take on this task (some may even enjoy it!), and many who even do it for free for various open source projects, but I've no clue how to recruit or connect with any that would be willing to do this for a job. Any tips for finding or connecting with such folks would be much appreciated. Attending in person won't be possible, but I'll have to keep an eye on this conference and see if they provide a way to post/share such opportunities.
- seabass-labrax 3y ago
  I think you might have more success advertising to sysadmins or devops engineer rather than developers. It's precisely the negative attitude, or at least apathy, towards packaging that makes it difficult to find employment where packaging is valued. On the other hand, a lot of the packaging related work has traditionally been the remit of the UNIX/Linux system administrator, and that as a profession is slowly moving towards automation as 'devops' - but it's still fundamentally the same concepts. Also, you could sprinkle in some 'optional but desired' skills and experience relating to packaging into your advertisements, anything from CMake and GNU Autotools to Nix and Podman. That would be enough to pique a packager's interest and differentiate it from the 'write-only' coding jobs!
  - saurik 3y ago
    I will second this advice; both of the engineers I have worked with who actively enjoyed being tasked with packaging software identified as systems operations / devops / site reliability engineering.
    - 3y ago
failuser 3y ago
Will the announce a package manager to manage package managers? Every language having a package manager is getting out of hand. Having a unified way to install packages across RPM, DEB and Gentoo is also enticing. Maybe even Mac and Windows. That was mostly a joke.
hamasho 3y ago
I like a package management system integrated with project management, such as JS's package.json or Python's pyproject.toml. I want to manage project scripts, tool configs, and dependencies in one place. It's sometimes annoying, especially for larger projects, but overall, I hope more languages adopt that style.
- brabel 3y ago
  I would think Java's Maven (since 2004) was the first to do this? https://maven.apache.org/index.html https://maven.apache.org/index.html
- regularfry 3y ago
  I really don't. It puts one tool in the position of having to be good at all those things; and implicitly puts one ecosystem in a privileged position compared to everything else in the project by default, rather than by choice. It also means the file format of that one tool needs to be hammered into shape for every use case, and if it's something lobotomised like JSON, everyone suffers. Give me a Makefile any day. Yes, that's a specific choice of top-level tool, but it's a better choice than most for that specific top-level job because you just shell out to whatever else you need. Not having to rebuild dependency management is a win, too, where you can take advantage of it.
lifeisstillgood 3y ago
After Feynman's death his blackboard had written upon it two things, one was "If I cannot recreate it I do not understand it". Software is so complex, dependencies so deep that we have to be experts in both minimising our dependancies and in recreating them from the ground up. In every team I join my first thing to hang on about is recreating the same builds time after time.
- mdaniel 3y ago
  I have a corollary about that: it's not open source if I can't build it Now there's for sure a spectrum there, since "can't" could mean a lot of different things to different people, but a good straight-face test is whether they have a CI build specification in the public repo since building in CI and a newcomer trying to build the repo often have very overlapping concerns
pipe_connector 3y ago
https://packaging-con.org/about https://packaging-con.org/about Lorem ipseum -- whoops!
- seabass-labrax 3y ago
  But at least now we know who's making the bespoke tableware for the conference!
qrush 3y ago
I hope this will be recorded because this is my favorite kind of 1.25x content.
em-bee 3y ago
there is still a lot of room to improve packaging. i really miss the conary packaging and build system. it was not perfect, but it essentially put packages into a revision control system so that for one version numbers of packages didn't matter any more. the whole set of packages for a release was locked into place so you could have a new release of the distribution with an older version of a package. and you could switch distribution versions like you can switch branches in git. at one point my system was so messed up that it wasn't really usable any more. even installing or removing packages didn't work. but i was able to run a command that would switch to the latest stable release version. conary then shuffled around downgrading several packages that i had installed to the right release version and getting me to a clean release state, so my system was workable again. neither rpm nor deb systems are capable of doing that, and i am not aware of any others either.
- seabass-labrax 3y ago
  NixOS and Guix are capable of that; Fedora Silverblue and Fedora Kinoite (the same technology, just with different default desktop environments) also similar conceptually, but are a little less flexible to manage than through their management CLIs than those of Nix and Guix. I think all of them would recover to a consistent and fully-functional state, but Silverblue/Kinoite would not necessarily remove the 'ghost' packages automatically.
- Cloudef 3y ago
  Nix is capable of that and I consider it golden standard right now, it also allows you do multiple things not related to "package management", such as configuration management, creating vms / docker images, cross-compiling, reproducible dev envs, deploying to AWS etc...
alfalfasprout 3y ago
Oh man, missed the deadline to submit a talk but we're working on some really cool packaging related to conda environments. Maybe for next year's conference. Excited to attend-- this is a topic that's becoming extremely important especially in the ML world where dealing with dependencies is a total nightmare and most of the solutions we've seen don't scale well to large orgs.
- ruby1111 3y ago
  Cool! We're also working on improving conda environments and the interaction with them. If you would like to have a talk find us through https://prefix.dev https://prefix.dev
sam0x17 3y ago
"Our PoW-based solution defends fierily" oof
mikenikles 3y ago
I've spent the last year managing all my packages with Devbox (https://github.com/jetpack-io/devbox https://github.com/jetpack-io/devbox). Local dev, cloud dev, CI, production – all with the same config file. Fingers crossed my talk submission for PackagingCon gets accepted. It'd be awesome to share this new way of working with a wider audience.
- mdaniel 3y ago
  I see this in almost every thread on this topic, but feel it buries the lede since its dependency upon nix makes it more complicated than it seems, at least every time I've revisited it. Maybe it's an artifact of its 0.x version, or the fact that I have improper expectations With regard to your "CI" use case, this is part of why I said I must have improper expectations because $ docker run --name dbox ubuntu:22.04 bash -c 'curl -fsSL https://get.jetpack.io/devbox | FORCE=1 bash; devbox init; devbox add awscli2; devbox add zulu@11' $ docker exec dbox du -hs /nix 4.1G /nix and that's just the simple version, on Linux, and thus is likely the happy-path in CI. When trying to use it locally on macOS, this here is just some "you wanna do _what_?!": https://github.com/DeterminateSystems/nix-installer/tree/v0.10.0/src/action/macos https://github.com/DeterminateSystems/nix-installer/tree/v0.... (not to pick on determinate.systems, the upstream is similarly facepalm: https://nixos.org/manual/nix/stable/installation/installing-binary#macos-installation https://nixos.org/manual/nix/stable/installation/installing-... )
galaxyLogic 3y ago
Package Manager is like a Librarian. Librarians don't write books, they organize them to make them easier for the reading public to find. Being a Librarian is a skillset that takes years of study. Library Science. https://www.bestmastersdegrees.com/best-masters-degrees-faq/what-is-library-science#:~:text=Library%20science%20is%20the%20field,and%20other%20materials%20in%20libraries https://www.bestmastersdegrees.com/best-masters-degrees-faq/....
- m463 3y ago
  You might find it interesting that basically the definition of a linux distribution is a package manager + a repository.
- anthk 3y ago
  Any skilled DBA would do years of Librarian "studies" in minutes.
  - saraton1n 3y ago
    I think that's a really narrow view of what librarians do. It's not just having stock of all the books, it's knowing the books that are relevant to particular fields of study, it's having a mastery of research and source-finding, and so much more.
samsquire 3y ago
I am a beginner in this space but I have some interest in trying to find solutions to the pain of package usage. * A new programming language and ecosystem could try to solve package management from day 0. ScrapScript is an example of this. I've heard good things about Go and Rust. * You can make package management fun by thinking of it as a data flow factory and like Factorio (which I've not played but I do get the feeling of that game) As it stands it's just lots of tedious boring busy work. * If only dependency usage was as enjoyable and straightforward as shopping and arranging bought things in a room. * I am investigating the modelling of packages as bundles of types foremost and state machines that can be traversed by the package manager to determine state interactions and compatibility automatically. * Changes to packages break everything. You could diff ASTs to see what's different. * I don't enjoy breaking changes. I have some old projects where I never pinned versions that cannot be built because I don't know what versions they work against.
- justcool393 3y ago
  > You can make package management fun by thinking of it as a data flow factory and like Factorio (which I've not played but I do get the feeling of that game) having played the game, Factorio is way more fun than package management
- quickthrower2 3y ago
  Simply having a sane standard library (as packages) goes a long way to making package management nice. Because then most packages are level 2 depending only on core libraries whose API rarely changes. Even JS/NPM, if it has this, would be a lot nicer to use. I find Python nicer than NPM just for this reason even though people grumble. And .NET even better. Elm is perhaps the best package manager because of the focus on developer experience there. Another good tip: have just one package manager for your ecosystem!
jmmv 3y ago
I suppose there might be others, but I just wanted to mention http://pkgsrc.org/pkgsrcCon/ http://pkgsrc.org/pkgsrcCon/, a conference on the pkgsrc packaging system. This had been going on for years, but seems to have stopped in 2019 due to the pandemic and not resumed...
regularfry 3y ago
For me, the packaging mechanism itself is a less important step than the idea of distributions: can I set up a collection of packages that is known to be mutually compatible? Or is the approach "one repository to rule them all"? This is where I always (when I was poking at it, a while back) ran into trouble with Cabal and Stack. It was always possible (likely, in fact) that I would select some set of libraries that managed to be mutually incompatible, so I had to go version-chasing to get something that worked. This is something that Linux distros had to solve right from the start, so it's built into the concept, but I only very rarely see it done at all, let alone done well, in language package managers.

189 points by droelf 3y ago

predictabl3 3y ago

Should've scheduled it in September. Folks could've popped in after NixCon ;).

lillecarl 3y ago
I don't quite get why we need PackagingCon when there's already NixCon ;)
hobofan 3y ago
It's directly after BazelCon which is held in Munich this year, and has some thematical overlap.

swyx 3y ago

oh i love ultra niche conferences like these. good luck and looking forward to it! looks like the CFP closed :/

seabass-labrax 3y ago
Unfortunate timing to be on HN - it only closed a couple of days ago. Out of interest, might you be able to share your paper/project here?
cik 3y ago
I emailed them because of that! Without it showing up here on HN, I'd never know it existed.

hashtag-til 3y ago

Surely the program will be packed.

peoplearepeople 3y ago
I'm pretty excited about it
tough 3y ago
I see what you did there, hasttag-til lmao
bnchrch 3y ago
Hopefully they have a good manager to keep things working and organized....
- felipellrocha 3y ago
  When will the schedule be determined?
  - bnchrch 3y ago
    I hope I dont have any _conflicts_ in calendar
layer8 3y ago
You'd think so, but it's a con.

serial_dev 3y ago

At first, I thought it's a joke conference site, but if I think about it, it's actually a great idea! Just goes to show how we are (or at least, I am) used to $PROG_LANG conferences, or Agile/SysAdmin/SRE/Mobile confs. Could be cool to have linting conf, code editor summit, etc.

pxc 3y ago
Relatedly: there actually is a configuration languages conference out there! 2021: https://2021.splashcon.org/home/conflang-2021 https://2021.splashcon.org/home/conflang-2021 2023 (upcoming): https://2023.splashcon.org/home/conflang-2023 https://2023.splashcon.org/home/conflang-2023

ISV_Damocles 3y ago

Would be fun of them to get a keynote speech from someone involved with EPS[1] (no, not that EPS[2]). I do wonder what parallels the two kinds of packaging have in common. [1]: https://eps.ieee.org/ https://eps.ieee.org/ [2]: https://en.wikipedia.org/wiki/Encapsulated_PostScript https://en.wikipedia.org/wiki/Encapsulated_PostScript

seabass-labrax 3y ago
As an expert in the software kind of packaging but only casually knowledgable about the electronics kind, I suspect rather little. However, the former is probably going to be much more prominent in the microelectronics world soonish, as dynamically configurable chips based on FPGAs are becoming very popular, and highlight more than ever how inadequate the conventional IDEs and SDKs for embedded software are. Proper software packaging is almost non-existent in embedded software engineering, but the current work-around of just using one company's SDK for everything won't scale to support all the FPGA cores that people want to use.

bnchrch 3y ago

This might be the most mundane topic Ive found myself naturally extremely excited about. If your a developer working full time in only one or two languages you may never experience just how good/bad you have it. When you do, its really eye opening. Every time I transition to a new language professionally it can be like opening a bag of Bertie Bott's Every Flavor Beans when you look into the packaging story. * Go binary release story is great but the gopath method for dependencies is annoying * Elixir has lockfiles and built-in package docs but the release story deviates too much * Javascript now that everything has settled into npm is a delight but the lack of stdlib, painful local aliasing and extremely heavy node_modules folder can be offputting * Python just sucks (lets hope poetry can bring the promised land of deterministic builds)

seabass-labrax 3y ago
The Python world won't improve as long as programmers add dependencies on libraries written in other languages and (here's the important part) attempt to compile those packages themselves within a Python build process. Poetry is a nice chapter in the Python package definition story, but it is only a tentative step to fixing the wider problem.
bluGill 3y ago
I firmly believe that languages should not manage packages. While it makes the simple cases easy for beginners, the trade off is mixing languages becomes harder. There is no perfect language and often mixing should be the right answer and we don't want any more friction there.
- seabass-labrax 3y ago
  I quite agree! And would it even be harder for beginners? When trying a new a program written in a language I don't use frequently, I usually spend a good half-hour working out what command to run to install the dependencies and going through the logs working out what implicit requirement wasn't in the README. A holistic package, even one written for a different software distribution than the one I use (Debian at present), would immediately get me 99% of the way there. PS. If you find yourself in the same situation I do, Repology is your friend: https://repology.org/ https://repology.org/

BigElephant 3y ago

naive question - doesn't docker 'solve' this?

treve 3y ago
The question is a bit short, so I'm inclined to say: no, the things they solve is only mildly related. But maybe you have a specific thing in mind that Docker solves, so feel free to share what you think so someone or me can say something more useful about this!
orange-mentor 3y ago
Not exactly. Most Docker containers rely on distro package managers. You're usually running apt or apk inside your Dockerfile. And the container system rootfs needs to be laid out. It's a non-trivial amount of work to do that and keep it up to date. I am a fan of building a traditional native package in a multi-step Docker build, and the final container artifact can be a simple `RUN deb -i my-pkg.deb` I find that targeting traditional system packages has benefits. 1) it's not really that hard, and 2) it forces you to lay things out consitently, or, at the very least, the distros conventions are helpful.
alfalfasprout 3y ago
NOPE. Docker neatly encapsulates the problem and allows you to somewhat ship a reproducible deployment... until something needs to be updated. Now either you rebuild your image (which may not be reproducible) or patch it (which comes with its own share of problems). Caching can also be a nightmare if your image is built from common stages. Dealing with vulnerabilities is also a pain especially for things already in production. Docker (or container images in general) are great but they solve a limited set of problems well and tend to hide others.
- chriswarbo 3y ago
  > Docker (or container images in general) are great but they solve a limited set of problems well and tend to hide others. I like container images and runtimes. Docker is awful, and its "inside-out" approach encourages and enforces bad practices.

throwawaaarrgh 3y ago

I can't wait for ShoelacesCon. Last year I couldn't make it; I was all tied up.

benatkin 3y ago

I hope they consider this: https://github.com/deislabs/bindle/blob/main/docs/invoice-spec.md https://github.com/deislabs/bindle/blob/main/docs/invoice-sp... Bindle seems interesting but I'm not quite sure how to use it or whether it will take off anytime soon. Maybe cargo has some of its interesting features.

seabass-labrax 3y ago
I don't understand yet what Bindle is trying to do. It seems to be half archive format, half package manager, yet not innovating in either area nor adding anything by their combination. Additionally, it explicitly doesn't support 'latest' tags or branches, which exist in package ecosystems for a reason.
- benatkin 3y ago
  It seems the client/server is neccesary. Not an issue for cloud projects composed of many servers and SDKs like Deis Labs or Fermyon, but an issue for others wanting to adopt it.

ary 3y ago

They have a YouTube channel and I hope they publish all of the talks after the fact. Should anyone from the conference read this it would be great if paid corporate packages were offered that made the recorded sessions available for download. https://www.youtube.com/@packagingcon9302 https://www.youtube.com/@packagingcon9302

binary132 3y ago

Unpopular opinion: old-style GOPATH semantics are significantly better than “package management”.

seabass-labrax 3y ago
It's not an unpopular opinion! Perhaps ironically, it is for the package management that software distributions provide (Debian, Fedora etc.) where GOPATH is most used - the Go modules system interferes with the guarantees that those distributions make about the builds, whereas GOPATH lets the distributions calculate dependencies themselves.
- binary132 3y ago
  almost as if the designers knew what they were doing

0x0203 3y ago

I'm not going to say where and I'm not asking for interested parties (we're not currently hiring anyway), but where I work (as a kernel/OS developer), package maintenance and management has been an ever-increasing burden to the point that we've tried hiring somebody specifically for the role. Unfortunately, it seems like this is a very specialized skill set that the vast majority of developers seem to find boring, uninteresting, and drudgerous, and finding someone qualified and interested has been exceedingly difficult. How would someone/a company go about finding people that are actually interested in this kind of work? There are clearly people who take on this task (some may even enjoy it!), and many who even do it for free for various open source projects, but I've no clue how to recruit or connect with any that would be willing to do this for a job. Any tips for finding or connecting with such folks would be much appreciated. Attending in person won't be possible, but I'll have to keep an eye on this conference and see if they provide a way to post/share such opportunities.

seabass-labrax 3y ago
I think you might have more success advertising to sysadmins or devops engineer rather than developers. It's precisely the negative attitude, or at least apathy, towards packaging that makes it difficult to find employment where packaging is valued. On the other hand, a lot of the packaging related work has traditionally been the remit of the UNIX/Linux system administrator, and that as a profession is slowly moving towards automation as 'devops' - but it's still fundamentally the same concepts. Also, you could sprinkle in some 'optional but desired' skills and experience relating to packaging into your advertisements, anything from CMake and GNU Autotools to Nix and Podman. That would be enough to pique a packager's interest and differentiate it from the 'write-only' coding jobs!
- saurik 3y ago
  I will second this advice; both of the engineers I have worked with who actively enjoyed being tasked with packaging software identified as systems operations / devops / site reliability engineering.
  - 3y ago

failuser 3y ago

Will the announce a package manager to manage package managers? Every language having a package manager is getting out of hand. Having a unified way to install packages across RPM, DEB and Gentoo is also enticing. Maybe even Mac and Windows. That was mostly a joke.

hamasho 3y ago

I like a package management system integrated with project management, such as JS's package.json or Python's pyproject.toml. I want to manage project scripts, tool configs, and dependencies in one place. It's sometimes annoying, especially for larger projects, but overall, I hope more languages adopt that style.

brabel 3y ago
I would think Java's Maven (since 2004) was the first to do this? https://maven.apache.org/index.html https://maven.apache.org/index.html
regularfry 3y ago
I really don't. It puts one tool in the position of having to be good at all those things; and implicitly puts one ecosystem in a privileged position compared to everything else in the project by default, rather than by choice. It also means the file format of that one tool needs to be hammered into shape for every use case, and if it's something lobotomised like JSON, everyone suffers. Give me a Makefile any day. Yes, that's a specific choice of top-level tool, but it's a better choice than most for that specific top-level job because you just shell out to whatever else you need. Not having to rebuild dependency management is a win, too, where you can take advantage of it.

lifeisstillgood 3y ago

After Feynman's death his blackboard had written upon it two things, one was "If I cannot recreate it I do not understand it". Software is so complex, dependencies so deep that we have to be experts in both minimising our dependancies and in recreating them from the ground up. In every team I join my first thing to hang on about is recreating the same builds time after time.

mdaniel 3y ago
I have a corollary about that: it's not open source if I can't build it Now there's for sure a spectrum there, since "can't" could mean a lot of different things to different people, but a good straight-face test is whether they have a CI build specification in the public repo since building in CI and a newcomer trying to build the repo often have very overlapping concerns

pipe_connector 3y ago

https://packaging-con.org/about https://packaging-con.org/about Lorem ipseum -- whoops!

seabass-labrax 3y ago
But at least now we know who's making the bespoke tableware for the conference!

qrush 3y ago

I hope this will be recorded because this is my favorite kind of 1.25x content.

em-bee 3y ago

there is still a lot of room to improve packaging. i really miss the conary packaging and build system. it was not perfect, but it essentially put packages into a revision control system so that for one version numbers of packages didn't matter any more. the whole set of packages for a release was locked into place so you could have a new release of the distribution with an older version of a package. and you could switch distribution versions like you can switch branches in git. at one point my system was so messed up that it wasn't really usable any more. even installing or removing packages didn't work. but i was able to run a command that would switch to the latest stable release version. conary then shuffled around downgrading several packages that i had installed to the right release version and getting me to a clean release state, so my system was workable again. neither rpm nor deb systems are capable of doing that, and i am not aware of any others either.

seabass-labrax 3y ago
NixOS and Guix are capable of that; Fedora Silverblue and Fedora Kinoite (the same technology, just with different default desktop environments) also similar conceptually, but are a little less flexible to manage than through their management CLIs than those of Nix and Guix. I think all of them would recover to a consistent and fully-functional state, but Silverblue/Kinoite would not necessarily remove the 'ghost' packages automatically.
Cloudef 3y ago
Nix is capable of that and I consider it golden standard right now, it also allows you do multiple things not related to "package management", such as configuration management, creating vms / docker images, cross-compiling, reproducible dev envs, deploying to AWS etc...

alfalfasprout 3y ago

Oh man, missed the deadline to submit a talk but we're working on some really cool packaging related to conda environments. Maybe for next year's conference. Excited to attend-- this is a topic that's becoming extremely important especially in the ML world where dealing with dependencies is a total nightmare and most of the solutions we've seen don't scale well to large orgs.

ruby1111 3y ago
Cool! We're also working on improving conda environments and the interaction with them. If you would like to have a talk find us through https://prefix.dev https://prefix.dev

sam0x17 3y ago

"Our PoW-based solution defends fierily" oof

mikenikles 3y ago

I've spent the last year managing all my packages with Devbox (https://github.com/jetpack-io/devbox https://github.com/jetpack-io/devbox). Local dev, cloud dev, CI, production – all with the same config file. Fingers crossed my talk submission for PackagingCon gets accepted. It'd be awesome to share this new way of working with a wider audience.

mdaniel 3y ago
I see this in almost every thread on this topic, but feel it buries the lede since its dependency upon nix makes it more complicated than it seems, at least every time I've revisited it. Maybe it's an artifact of its 0.x version, or the fact that I have improper expectations With regard to your "CI" use case, this is part of why I said I must have improper expectations because $ docker run --name dbox ubuntu:22.04 bash -c 'curl -fsSL https://get.jetpack.io/devbox | FORCE=1 bash; devbox init; devbox add awscli2; devbox add zulu@11' $ docker exec dbox du -hs /nix 4.1G /nix and that's just the simple version, on Linux, and thus is likely the happy-path in CI. When trying to use it locally on macOS, this here is just some "you wanna do _what_?!": https://github.com/DeterminateSystems/nix-installer/tree/v0.10.0/src/action/macos https://github.com/DeterminateSystems/nix-installer/tree/v0.... (not to pick on determinate.systems, the upstream is similarly facepalm: https://nixos.org/manual/nix/stable/installation/installing-binary#macos-installation https://nixos.org/manual/nix/stable/installation/installing-... )

galaxyLogic 3y ago

Package Manager is like a Librarian. Librarians don't write books, they organize them to make them easier for the reading public to find. Being a Librarian is a skillset that takes years of study. Library Science. https://www.bestmastersdegrees.com/best-masters-degrees-faq/what-is-library-science#:~:text=Library%20science%20is%20the%20field,and%20other%20materials%20in%20libraries https://www.bestmastersdegrees.com/best-masters-degrees-faq/....

m463 3y ago
You might find it interesting that basically the definition of a linux distribution is a package manager + a repository.
anthk 3y ago
Any skilled DBA would do years of Librarian "studies" in minutes.
- saraton1n 3y ago
  I think that's a really narrow view of what librarians do. It's not just having stock of all the books, it's knowing the books that are relevant to particular fields of study, it's having a mastery of research and source-finding, and so much more.

samsquire 3y ago

I am a beginner in this space but I have some interest in trying to find solutions to the pain of package usage. * A new programming language and ecosystem could try to solve package management from day 0. ScrapScript is an example of this. I've heard good things about Go and Rust. * You can make package management fun by thinking of it as a data flow factory and like Factorio (which I've not played but I do get the feeling of that game) As it stands it's just lots of tedious boring busy work. * If only dependency usage was as enjoyable and straightforward as shopping and arranging bought things in a room. * I am investigating the modelling of packages as bundles of types foremost and state machines that can be traversed by the package manager to determine state interactions and compatibility automatically. * Changes to packages break everything. You could diff ASTs to see what's different. * I don't enjoy breaking changes. I have some old projects where I never pinned versions that cannot be built because I don't know what versions they work against.

justcool393 3y ago
> You can make package management fun by thinking of it as a data flow factory and like Factorio (which I've not played but I do get the feeling of that game) having played the game, Factorio is way more fun than package management
quickthrower2 3y ago
Simply having a sane standard library (as packages) goes a long way to making package management nice. Because then most packages are level 2 depending only on core libraries whose API rarely changes. Even JS/NPM, if it has this, would be a lot nicer to use. I find Python nicer than NPM just for this reason even though people grumble. And .NET even better. Elm is perhaps the best package manager because of the focus on developer experience there. Another good tip: have just one package manager for your ecosystem!

jmmv 3y ago

I suppose there might be others, but I just wanted to mention http://pkgsrc.org/pkgsrcCon/ http://pkgsrc.org/pkgsrcCon/, a conference on the pkgsrc packaging system. This had been going on for years, but seems to have stopped in 2019 due to the pandemic and not resumed...

regularfry 3y ago

For me, the packaging mechanism itself is a less important step than the idea of distributions: can I set up a collection of packages that is known to be mutually compatible? Or is the approach "one repository to rule them all"? This is where I always (when I was poking at it, a while back) ran into trouble with Cabal and Stack. It was always possible (likely, in fact) that I would select some set of libraries that managed to be mutually incompatible, so I had to go version-chasing to get something that worked. This is something that Linux distros had to solve right from the start, so it's built into the concept, but I only very rarely see it done at all, let alone done well, in language package managers.