I generally agree with Stefan’s point that right now 3 days waiting time does more good than harm, but for future reference here are some use cases when it annoyed me pretty much:
Publishing dependent packages
Usually I have whole chains of packages, say, A <- B <- C
, where A
is a pure library, B
depends on it and C
depends on both and is private. To test C
for production, I need to ]add
them as if they have already been registered and even include concrete versions of A
and B
and run tests, but for 2 new packages it means up to 6 days before I can be sure C
is ready to be deployed.
Perhaps I could use LocalRegistry and deploy without any waiting, but then I would have very real motivation to actually make these packages public later.
Figuring out structure of dependent packages
Another problem when developing multiple interdependent packages at the same time is figuring out what code should go where. In my day-to-day job in industry, where I mostly write in Python and Scala, we restructure packages approximately every 3 months. Sometimes such packages live for just a few days: we create a new package, try out new structure, realize its limitations and refactor again.
In open source and with public packages it happens more rarely, but still happens. For example, I remember Hadoop ecosystem maturing, new packages being separated, merged with others and deprecated pretty quickly. Usually these are not user-facing packages - no, that ones stay stable - but some helper libraries covering specific needs.
Moving common functions to a separate package.
Once I had a set of utils that I used in 2 or 3 packages. These were very simple things without their own common domain, e.g. @get
- a macro similar to get
, but not evaluating second argument unless needed, or macro @runonce
which avoided re-evaluation of some pieces of code, etc. I thought about creating a package with some dummy name like LittleGoodThings
and moving all the utils there, but I couldn’t come up with a reasonable description and decided simply to duplicate the code.
Announcing a package
You know this feeling when you are ready to release first version of a package you’ve been working on for several months. Over the weekend you finish last tests, write docs and encouraging text of announcement to post it here, on Discourse. Then you submit a PR and… wait until Wednesday until it gets merged. Over this time the enthusiasm fades, you get back to daily job and come back to the package in the middle of Friday. Not a big price for something you’ve spent on several months, but it also doesn’t encourage for more active development.
None of these use cases were really blocked by the waiting time, but it made things pretty inconvenient, so hopefully in some distant future this last issue will also be overcome.