Any namespace/package/version can be deleted/disabled by the sudoadmin (org admins) but as it is currently a test registry you can ping me I would be happy to erase any namespace/package/version.
There can be multiple namespaces like music, graphics, owned by a single owner and each namespace serves a different functionality like music namespace has all the package with music related functionalities and categories and keywords can be used to in fpm.toml to set the hierarchy for packages. Please feel free suggest more functionalities to the registry.
Can you please confirm if should I delete GPF namespace ? @urbanjost
When the next version of fpm(1) is released is when I wanted to re-test so if you could delete it any time before then I wanted to test the next version from the ground up with the new version.
RE: desired features
I was hoping to see an ability to register programs as well as libraries; where plug-ins and programs could be registered and easily installed.
Assuming over the long term external support of packages will disappear it might be useful to have an option to install the package something like the ânewâ command creates a package directory, but populated with a package instead of the skeleton files. The reverse of âpublishâ in a sense.
The ability to edit longer package descriptions on the registry site would be nice as (at least currently) the packages are not expanded on the registry site itself.
When using other packages as dependencies from github repositories the git command allows just the main branch to be pulled. Theoretically this would allow something like the gh-pages branch to include
documentation and test data and other files that you want long-term; but to be able to pull an abbreviated
package for efficiency when just using the package as a dependency. I am wondering if when a package
is published it should store two archive files. One including everything for future developers or people wanting to learn more about the package; but one abbreviated to just the files used by the build model
when building the main package? Looking at netlib for lessons to learn the repository should contain everything available about the package; but this can make for a very large file. Perhaps a registry cache makes big package files a minor issue(?) so not sure yet how important it will be to have two files.
A view somewhat like the @Beliavsky lists at Beliavsky (Beliavsky) / Repositories ¡ GitHub
where you could search and sort by categories and keywords supplied in the manifest file, with a matching CLI program like the original fpm-search plugin is desirable.
For a quick way to test that is great; but then the description is not meaningful for anything accept the registry; so anyone making use of the description (I have such a plugin that displays the metadata of a package when you enter âfpm versionâ, for example). ).
$ fpm version
name : prep
version : 10.0.0
license : MIT
author : John Urban
maintainer : urbanjost@comcast.net
copyright : 2020 John Urban
description : Fortran pre-processor
categories : preprocessing
keywords : preprocessor, fortran, fpm, General Purpose Fortran
homepage : https://github.com/urbanjost
or the fpm option âfpm --versionâ which is very similar.
So in the long term using a âmagic stringâ or âmagic numberâ in an existing field that conflicts with current use is probably not desirable. That being said I made a namespace called CLI to try it as-is to see how it works. Not familiar with how it works behind the curtain, but it everything worked like it did before but you get an extra button to read if a README.md file exists work?
I did not notice a few packages did not have a description until they showed up with âdescription not providedâ like M_sets in namespace GPF. So I added the missing descriptions and incremented the version number and created new versions. The versions show up but the description remains undefined.
So it looks like the metadata from the first entry is always used? I would expect the metadata for the latest version would be used, as the latest version is what you get if you use the registry package without a version. Ideally, you could click on different versions and the metadata would change. Now clicking on a version causes it to download. It seems there should be some way to browse the versions without downloading.
Response from the registry is getting very slow. If it is because the test registry cannot handle a lot of packages yet you can delete the GPF namespace; but ultimately I would hope there are thousands of packages some day (equivalent registries for Java, Rust, Python have many tens of thousands or more packages, for example). Hope there is some other reason for the slow response but it seems to be persistent not just a temporary slowdown(?)
we are currently running testing phase with free serverless architecture which has daily allocated dedicated cpu time (1s) after which it is slowed down. But will ensure to check for all other bottlenecks.
The packages/versions are validated on daily github actions and then their description is added from their tarballs.
If the file exists and the description in the fpm.toml is README.md then its content is read into the description of package.
I do agree to that, I am thinking of another alternative of something like registry-description in fpm.toml (non mandatory but only for registry).
I will be running all the tests fro all the packages again as there were some bug fixes and markdown rendering problems and will be patching the bugs on fpm side and release a new version soon.