Fpm version 0.10.1 released: centralized registry playground

Announcements
1

We have just released v0.10.1 of fpm with a series of new features. Among others, this release contains great improvements in whole set of registry functionalitites, fpm model support and support package downloads from registry.
For a full list of the new features see the GitHub Release Notes

This release introduces fpm support for uploading packages to the fpm-registry server directly from the command-line interface, via

fpm publish --token <token-here>

fpm will now interact with a web interface that will help to manage the namespaces & packages.

We have made an experimental registry available online at https://registry-phi.vercel.app/.

We welcome testing from the fortran-lang community: here are a few steps to get started.

First of all, you will need to register a user account.
For uploading your package to the registry, you will have to step by step follow the following points:

  1. Register yourself as a user. You will require a unique username, email & password to set up your account. you will need to verify your email id to login into the registry, you will receive a mail to verify your email id.
  2. For uploading a package from fpm, you will have to first create a namespace. A namespace represents a collection of packages. Each package is published under a namespace in order to avoid collision of same package names. Namespace names will be unique always.
  3. Now, that you will have created a namespace with a unique name and a nice description. You can go to dashboard by from the dropdown options in the Navigation bar on top.
  4. In the dashboard, you can see the namespace that has been created by you. You can now generate a token for this namespace.
  5. Use this token to upload packages from the fpm using the CLI:
fpm publish --token <token-here>

After completing the above steps, you will receive a response in the fpm command line interface whether your upload was successful or not.

If your upload was successful, you can now again go to the registry frontend and check the dashboard. It should display the package uploaded by you. all the packages uploaded on the registry are run through a series of tests that ensure the package uploaded is valid. You can now Add/Remove maintainers to your package. Mantainers have the rights to operate on the same package.

*** Please note: the current registry is a playground: its database will be fully deleted once its functionality is established. Please do not use it for production yet! more information will follow then. ****

To download a package from registry: (add this line to fpm.toml)

package_name = {"namespace" =  "namespace_name"}

for example:

M_framework = {"namespace" = "urbanjost"} # this will use the latest version. you can also use it with versions.

Thanks to everyone who contributed to this release! We are eager to receive community feedback and suggestions for user experience here on Fortran Discourse.

Portions of the work present in this release have been funded by the Sovereign Tech Fund.

CC: @certik @awvwgk @FedericoPerini @arteevraina @minhdao

20 Likes
2

Thanks, I have just upgraded successfully.

With fpm 0.10.0, I had encountered a problem probably due to a bug in GNU Fortran (Ubuntu 13.2.0-4ubuntu3). Curiously, this time everything ran smoothly, although the GFortran version in my Ubuntu 23.10 is still exactly the same: Ubuntu 13.2.0-4ubuntu3.

2 Likes
3

When attempting to register an ID no e-mail confirmation code is ever recieved and the registration page says “KeePassPC is not running”, which I assume might be related. A few questions even though I could not get any response

  • the previous registry playground (fpm - registry) is officially defunct?
  • any size restrictions on packages?
  • any changes to the capabilities of the repository itself? e.g.:
    • something to distinguish between applications, plug-ins, and libraries?
    • subgrouping a namespace like a subsection for command-line parsers,
      poskanzer graphics, system interfaces, numeric computation, sorting, …?
    • a description and keywords to categorize projects that would automatically
      appear in a package index?
  • any replacement for fpm-search?
1 Like
4

Regarding

package_name = {"namespace": namespace_name}

should be an equal sign instead of a colon, should it not?

package_name = { namespace = namespace_name}

or more concretely:

M_framework = { namespace = "GPF" }
1 Like
5

@urbanjost there was a typo in the post, Thanks , fixed it. The last 2 formats are valid formats:

package_name = { namespace = namespace_name}

M_framework = { namespace = "GPF" }
6

On checking the server logs, It says the email has been sent to your mail id maybe it went into your spam folder or due to institutional id it was restricted. I have verified your account for the registry , you can try out the registry.

The previous registry is officially defunct as we have shifted to new auth mechanishm JWT and It was cleaner to make a new release from a new url. (We will pull down the older playground soon).

There is a tarball size restriction of about 4MB. This restriction is setup by vercel (serverless free hsoting provider) . after the testing phase we intend to move to paid hosting , That can support upto 150MB of tarball size.

We have added support for descriptions, keywords, categories for a package which can be used to search the package index. applications, plug-ins, and libraries can be distinguished by using keywords which will be read from fpm.toml file. we have provided functionalities so that a single user may own multiple namespaces which can be used for different functionalities.

We have added support for searching the registry on the website for any term in categories, keywords, descriptions of packages, for fpm cli we haven’t provided the search functionalitites to prevent the botting problems as faced by PyPI.

newly uploaded packages on registry are validated (run through a set of tests) on a daily basis using github actions.

2 Likes
7

I tried to publish my package codata and it worked perfectly. :grinning:

2 Likes
8

I uploaded several packages with no dependencies and they showed up, but virtually all my other packages are dependent on a test framework and the ones that uploaded do not download (Pending validation, perhaps? Would be useful if a message indicated that).

That raises the question as to whether fortran-stdlib dependencies will be allowed, as currently all dependencies must be valid repository packages? Will fortran-stdlib be maintained as a package in the repository?

1 Like
9

If the package has not been verified , the message Package Under Verification is shown on the package page. I was able to download and use some of your packages. Can you please share a example package ? ( logs also don’t show any restricted download requests).

Thanks , This let to the discovery of some bugs on namespaces functionality affecting the viewing of packages on the namespace page, I have pushed some patches to fix this.

We intend to build the registry in an bottom to top manner. Thus, all the dependencies need to be valid repository packages. fortran-stdlib is already supported as a metapackage for the fpm.

10

I intend to play with it later this week, but I do have a question about the

aspect. Does this include dev-depencencies? If so, I’ll have a minor catch-22 to solve for a few of my packages. I.e. veggies depends on iso_varying_string and strff, but those both use veggies for testing. I can of course drop the test suite for an initial upload of iso_varying_string and strff, so not a show stopper.

1 Like
11

I had the issue with test-drive which does not comply to the module naming convention. I had to remove it as a dependency from fpm.toml to be able to upload my package.

1 Like
12

We will soon open a PR to test-drive with the module naming conventions to support it as a package.

1 Like
13

We can build the packages from their non dependent initial versions. we also intend to make a functionality to support upload of packages with catch-22 problem.

14

So if you are successfully pulling down some of the packages I uploaded do I have a syntax error
in my dependencies?
In fpm.toml I have

 M_framework = {"namespace" = "GPF" }

and always get

 Downloading 'https://fpm-registry.vercel.apppackages/GPF/M_framework' -> '/tmp/filew4lFDX'
 <ERROR> *cmd_build* Model error: Error downloading package from 'https://fpm-registry.vercel.apppackages/GPF/M_framework'.
 STOP 1
1 Like
15

Thanks @urbanjost for reporting this bug, I will be patching this soon.

16

in case you had looked at these yet, there appears to be a missing slash in dependency.f90

-    target_url = global_settings%registry_settings%url//'packages/'//self%namespace//'/'//self%name
+    target_url = global_settings%registry_settings%url//'/packages/'//self%namespace//'/'//self%name

And my version of git(1) has no --add-file option in src/fpm/git.f90:

-    add_files = trim(add_files)//' --add-file='//adjustl(additional_files(i))
1 Like
17

I wanted to publish my package yaeos but I’m having trouble with the module-naming fpm option (which I wasn’t aware of it existing since it is not on the manifest reference but I’m really glad it exists!),

fpm publish --token "<my_token>"
 ERROR: Module yaeos_mixture in ././src/mixture.f90 does not match its package name (yaeos).
 ERROR: Module yaeos_thermoprops in ././src/thermoprops.f90 does not match its package name (yaeos).
 ERROR: Module yaeos_constants in ././src/constants.f90 does not match its package name (yaeos).
...continues

Is not that way of naming modules correct? What might I’ve been missing?
Besides that, my package depends on stdlib which is not enforcing module-naming, would that mean that if my package depends on a package that doesn’t enforce module-naming it would be impossible to get it published?

Warning: Dependency stdlib does not enforce module naming, but project does. 
 ERROR: Module stdlib_stats_moment_scalar in build/dependencies/stdlib/src/stdlib_stats_moment_scalar.f90 does not match its package name (stdlib).
 ERROR: Module stdlib_ansi_operator in build/dependencies/stdlib/src/stdlib_ansi_operator.f90 does not match its package name (stdlib).
 ERROR: Module stdlib_hash_64bit in build/dependencies/stdlib/src/stdlib_hash_64bit.f90 does not match its package name (stdlib).
 ERROR: Module stdlib_stats_mean in build/dependencies/stdlib/src/stdlib_stats_mean.f90 does not match its package name (stdlib).
 ERROR: Module stdlib_error in build/dependencies/stdlib/src/stdlib_error.f90 does not match its package name (stdlib).
...continues
18

The rules for naming modules are explained here fpm naming. Your naming is missing an additional underscore after the package name.

Besides that, my package depends on stdlib which is not enforcing module-naming , would that mean that if my package depends on a package that doesn’t enforce module-naming it would be impossible to get it published?

As far as I know, yes. The fpm registry will only contain packages with valid naming.

3 Likes
19

Thank you @urbanjost. I’ve been addressing these bugs in my repository (fix: url bug · henilp105/fpm@7d5a99d · GitHub). I’ll open a pull request shortly after I’ve identified any additional bugs. we will be releasing a new patch/minor version of fpm after these bugs are patched.

20

I added a few dozen packages; added new versions to a few; and one plug-in program and one application; both with a decent number of dependencies on repository dependencies and the only
oddity I am seeing is when I use M_io and M_framework from the GPF namespace I get a warning about them not obeying the module naming convention; which they had to to be added to the registry (but everything proceeds to build) and a segfault I get using “module build --show-model” that is a regression error as it works with earlier versions but that is probably unrelated. Since there is no ability to remove packages I guess I can put in a new version of everything to test when the new version is released; but I would like to try everything from the ground up when the new version is released. Is it possible for the GPF namespace to be erased since this is just a test registry?

So my tests have packages with no dependencies and then packages dependent on those; and then a program and a plug-in that use over seven packages;but have not tried all packages as dependencies or created anything that uses anything other than packages from the GPF namespace. So far I did not see anything on allowing a user to have multiple namespaces and/or organize by topics (CLI, graphics, numeric, wrappers for C libraries … is there anything actually available for testing yet that allows for creating some kind of hierarchy?

1 Like