Hi guys,
at the moment there is approximately 250 packages shipping projects
written in go. In general, each project has its own set of dependencies
and provided import paths (golang packages). As usually each package has
four active branches. Thus, we are dealing with approximately 1000 spec
files, all potential candidates for rebases/updates and bug fixes. Each
update can break backward compatibility. Some projects may require
different commits of the same dependency.
What are the most hot packaging problems in the golang ecosystem?
- bundled vs. de-bundled dependencies
- updates of spec files
- backward compatibility issues
- integration testing
- best practises
*bundled vs. de-bundled dependencies)*
As mentioned in [1] some projects can not be build from de-bundled
dependencies. Either caused by requirement for more commits of the same
dependency or due to daily updates which require reviews of new
packages. The current effort is to minimize number of bundled dependencies.
*updates of spec files)*
In general, each spec file has to be manually updated. Either if it is a
list of build-time (runtime) dependencies, list of provided packages or
a list of tests. Secondly, you never know if you break dependencies of
other projects when you change project's API. Last but not least, when
you want to update to newer release (or commit) of a golang project, new
dependencies may appear. Resulting in generating of new spec files,
reviews, overrides and dreamless hours of routine steps. The current
effort is to detect all dependencies and provide warnings about their
removal and to detect portion of API that is used by other projects. At
the same time to provide more complex tooling to generate better spec
file with less dependencies.
*backward compatibility issues)*
With 1000 spec files it is difficult to keep API of all projects
consistent. No matter what you do you will always break something. At
the moment we can provide a dependency graph only. It can tell you if a
given dependency is available and what projects requires the dependency.
*integration testing)*
Some golang projects need additional services running. It would be great
to be able to CI all golang packages to see what is broken and what is
suitable for fixing.
*best practises)*
Well...
And there are other issues which when resolved can make the world better
place to live. Mentioning some:
- generator of self-standing dvel subpackages [2]
- detectors of bundled deps [3]
- multi spec file generators [4]
- partial spec file generator [5]
- better lint
*What can you do to make the world a better place?*
Join us and contribute on gofed [6]. Currently we are in a phase of
implementing new architecture, extending current and introducing new
functionality. At the moment we aim to support golang language. In
future, there is no reason not to extend the support to other languages.
The top most goal is to implement health check analysis. Once detection
of used symbols in API is done, we can provide better feedback during
updates of packages and make the ecosystem health enough to be able to
grow fresh and strong golang projects.
What can you do right away? Play with gofed and infrastructure, help
testing and documenting.
Ideas and improvements are welcome.
[1] https://fedorahosted.org/fpc/ticket/382#comment:37
[2] https://github.com/gofed/gofed/issues/36
[3] https://github.com/gofed/gofed/issues/42
[4] https://github.com/gofed/gofed/issues/49
[5] https://github.com/gofed/gofed/issues/55
[6] https://github.com/gofed/gofed
[7] https://github.com/gofed/infra
Go nuts!!!
Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
