One of my goals with Telescope is extracting features into generic Atmosphere packages that can be shared with the rest of the community. But the current package workflow makes that pretty hard.
Problem 1: Dependencies on Local Packages
For example, I built Telescope using a modular package architecture to make it easier to add and remove features as needed. But I can’t publish any of these packages to Atmosphere, because they all depend on other packages which arent published to Atmosphere.
So either I publish every package to Atmosphere (including a lot that are only relevant to Telescope itself), or I can’t publish any.
I thought I could avoid this by using
imply instead of
use, but that doesn’t help.
Let’s say I do manage to somehow work around the first issue, and I publish my Telescope packages to Atmosphere.
Now the issue is actually working on them. I know about
PACKAGE_DIRS, but it’s not a perfect solution yet. First of all, it’s pretty opaque: how do you know when a package is being loaded locally, or remotely? How do you switch between both?
It also has its own issues. For example, I was working with a local copy of a package at version
0.7.7 while the published one is at
0.7.5, and I’m now unable to deploy using Mup because of a
Potentially incompatible change required to top-level dependency error.
All of this makes it very hard to embrace the package ecosystem, especially if I have to find a way to explain all that to new Telescope users.
So I’m not sure what the solution is, but I think it’s worth having the conversation.