Fpm version 0.8.2 released: centralized registry playground

Announcements
21

There are a lot of things to think about, I am sure. `I might have a package that only runs in a particular programming environment, like only on MSWindows or only with a particular compiler, so automating testing could be particularly problematic.

It is probably reasonable to make it difficult to remove packages so they can be relied on; so it would be useful for fpm(1) to be able to report when a package is deprecated. So if I find a bug in a package and put out a new release there would be some automated way `that someone using the package get a warning when using the package. That would be useful for fpm in general. If once released a package is immutable that that would be difficult to have a method that worked both for for a repository and for general user packages, for example.

If the repository is limited to 4.5 Megabytes it often could not include test data, extensive documentation, etc. But if not self-contained if the original package is removed or changed then that type of information will be lost.

Looking forward to the next iteration.

2 Likes
22

Limiting dependencies to the same registry seems problematic. If I want to use a graphics package, a unit testing framework, a linear algebra routine that is registered but not find in the same registry I could not use it as a dependency and still register the package? It seems like that would be very limiting, or require me to make copies (assuming the license allows it) of any package I wanted to use.

For fpm(1) packages I just have the same CD/CI script for everything, one file per environment I found or made on github; and they all just call “fpm test”. Packages that need infrastructure (ie. maybe the fpm(1) package is a wrapper for sqlite3, a graphics library, or any C/C++ library …) gets particularly complicated. A self-contained Fortran or C/C++ package is easy by comparison.
So such “dependencies” cannot be part of the registry. Since those kinds of external dependencies will be common (IMO) allowing registered fpm(1) packages seems minor in comparison.

Why the restriction? Will packages be removable once registered?

Do you envision the automated tests being required just to register, or will they be run periodically?

Testing interactive packages, GUI and graphics interfaces, becomes really hard to completely automate.

I have several packages that require a platform to be POSIX-compliant; which vanilla MSWindows is not. So at a minimum automated tests would require allowing a selection of platforms to test on.

23

This poses a Catch-22 problem for packages with mutual dependency. I.e. my veggies test framework uses iso_varying_string, but iso_varying_string uses veggies for testing. How could I initially get either of them added to the registry?

I think we should encourage packages to use dependencies from the (a) registry, and not directly from a git repository, but I don’t think it should be enforced by the registry upload mechanism.

1 Like
24

Well I believe that would be a circular dependency, not exactly smooth to deal with.

Unless I assume there’s an early version of veggies that does not rely on iso_varying_string or the other way around. This is the only chance that a first build can ever have happened. So you could start uploading the version that doesn’t depend on the other, and keep building from that:

  • publish veggies 0.1.0 (no dependencies)
  • publish iso_varying_string 0.1.0 (depends on veggies 0.1.0)
  • publish veggies 0.2.0 (depends on iso_varying_string 0.1.0)
    etc…

These issues will become less and less likely as the registry becomes more populated. Another option might be to allow batch uploads, where intertwined packages can be uploaded simultaneously, but I’m not sure I’m a fan of that.

Another option is to just let people use any git dependencies also in registry packages. What would be the drawbacks of such a decision?

25

This sounds like a development dependency only, so technically you probably want to upload iso_varying_string first.

1 Like
26

Correct. If it’s not enforced for [dev-dependences] then I think I’m fine.

2 Likes
27

Circular dependencies indeed are quite a special case and hopefully can be avoided. If needed, we can allow overriding the default with a command line flag or some flag in fpm.toml.

1 Like
28

Thanks @vmagnin, some of the bugs should be fixed now:

Considering fpm help (@urbanjost), yes that will absolutely be added. But for now you can refer to the fpm docs, which have just been updated.

Global config file and registry settings:

https://fpm.fortran-lang.org/en/spec/manifest.html#global-config-file

Manifest configs:

https://fpm.fortran-lang.org/en/spec/manifest.html#dependencies-from-a-registry

Package upload:

https://fpm.fortran-lang.org/en/spec/publish.html

4 Likes
29

Thanks @minhdao !
I confirm that it now works in Linux Ubuntu 23.04. I have published gtk-fortran in the registry site.

I then tried with my gtkzero_fpm repository, which uses gtk-fortran as a dependency but obtained that message:

gtkzero_fpm$ fpm publish --token e......................3
<ERROR> Do not publish packages containing git dependencies. 'gtk-fortran' is a git dependency.
STOP 1

With other projects like my musical projects Forsynth and Formidi, I have obtained that message:

formidi$ fpm publish --token e....................3
 Uploading package ...
{"code":400,"message":"Invalid license identifier GNU GPLv3. Please check the SPDX license identifier list."}

It seems I should use license = "GPL-3.0-or-later" instead in my fpm.toml files.

2 Likes
30

After updating the fpm.toml file with "GPL-3.0-or-later", I have successfully uploaded my Formidi project in a music namespace:

formidi$ fpm publish --token 8.............7
 Uploading package ...
{"code":200,"message":"Package Uploaded Successfully."}

I have got a question about the philosophy of namespaces: how should we name them? For example, for my musical projects should I create a music namespace? or a vmagnin_music namespace?

In the first case, it would be for anybody and I could add admins using the web interface. I guess that a new admin could also add other admins in that namespace? If I understand, each admin is responsible for accepting or rejecting new projects inside the namespace?

2 Likes
31

When naming namespaces, it is important to choose names that are descriptive and easy to remember. The name should give users a good idea of what the namespace contains.

Regarding the convention, I would follow the Fortran variable name naming conventions. But, we don’t necessary want to limit the namespace naming using variable naming convention.

We also have some basic checks for namespace naming implemented here.

Regarding the roles of the different users. Here is the documentation :

Roles in Fpm Registry.

  • Namespace Admins.

  • Namespace Maintainers.

  • Package Maintainers.

  • Namespace Admins:

    • Generates tokens for namespace.
    • Adds other users as admins.
    • Removes admins.
    • Add maintainers to namespace.
    • Remove maintainers from namespace.
    • Add maintainers to the packages (under that namespace)
    • Remove maintainers from the packages (under that namespace)

  • Namespace maintainers:

    • Generates tokens for namespace.
    • Adds maintainers to the namespaces.
    • Adds maintainers to the packages (under that namespace)
    • Removes maintainer from the packages (under that namespace)

  • Package maintainers:

    • Adds users as maintainers to the package.
    • Generate Token for a package (WIP)
6 Likes
32

Thanks for mentioning this. We are currently accepting the license identifiers that are mentioned here

This is also mentioned in the documentation Package upload — Fortran Package Manager

2 Likes
33

Thanks for these details @arteevraina
I will translate the doc when I have time.

3 Likes
34

If fpm is built in debug mode, any dependency I tried from the test repository gets this traceback:

traceback

At line 184 of file build/dependencies/jonquil/src/jonquil/lexer.f90
Fortran runtime error: Substring out of bounds: upper bound (712) of ‘lexer’ exceeds string length (711)

Error termination. Backtrace:
#0 0x1463305ad700 in ???
#1 0x1463305ae259 in ???
#2 0x1463305ae8d6 in ???
#3 0x560e779c167e in next_token
at build/dependencies/jonquil/src/jonquil/lexer.f90:184
#4 0x560e779c1c31 in __jonquil_lexer_MOD_next
at build/dependencies/jonquil/src/jonquil/lexer.f90:159
#5 0x560e778e0f98 in next_token
at build/dependencies/toml-f/src/tomlf/de/parser.f90:760
#6 0x560e778e2eef in consume
at build/dependencies/toml-f/src/tomlf/de/parser.f90:658
#7 0x560e778e39f2 in parse_inline_table
at build/dependencies/toml-f/src/tomlf/de/parser.f90:611
#8 0x560e778e4bf4 in parse_keyval
at build/dependencies/toml-f/src/tomlf/de/parser.f90:494
#9 0x560e778e994c in parse_root
at build/dependencies/toml-f/src/tomlf/de/parser.f90:134
#10 0x560e778ea358 in __tomlf_de_parser_MOD_parse
at build/dependencies/toml-f/src/tomlf/de/parser.f90:105
#11 0x560e779be0fc in __jonquil_parser_MOD_json_load_file
at build/dependencies/jonquil/src/jonquil/parser.f90:71
#12 0x560e779710cc in __fpm_downloader_MOD_get_pkg_data
at ././src/fpm/downloader.f90:42
#13 0x560e7785d15b in __fpm_dependency_MOD_get_from_registry
at ././src/fpm/dependency.f90:678
#14 0x560e7785e41c in __fpm_dependency_MOD_resolve_dependency
at ././src/fpm/dependency.f90:594
#15 0x560e77862c9a in __fpm_dependency_MOD_resolve_dependencies
at ././src/fpm/dependency.f90:555
#16 0x560e7786866d in __fpm_dependency_MOD_add_project
at ././src/fpm/dependency.f90:327
#17 0x560e777c3352 in __fpm_MOD_build_model
at ././src/fpm.f90:55
#18 0x560e777a9ca3 in fpm_MOD_cmd_run
at ././src/fpm.f90:560
#19 0x560e77773291 in MAIN
at app/main.f90:78
#20 0x560e77773791 in main
at app/main.f90:12

35

@urbanjost see lexer%chunk out of bounds in Windows build · Issue #15 · toml-f/jonquil (github.com): are you using gcc/gfortran <=9?

I had also found that issue, haven’t dug deeper, but that is solved by upgrading to gfortran-10.

36

Weblate seems not synchronized with the fpm doc site. The French translation is still at 100%, although I have not yet translated these pages:
- Module name requirements
- Package upload
- Fpm version 0.8.? released
and also additions in the Manifest reference page.

1 Like
37

Using gfortran-11. Not where I can look but a quick glance looks like it is exceeding bounds; suggested fix probably has a a redundancy in it; can look later but perhaps some tests passed because compiled with array bound checks on? Will run (and smack memory) without bound checks on.

1 Like
38

Please open a PR on the fpm page and we can better investigate. Are you building fpm with fpm build —profile=debug ?

39

yes. Building it multiple ways but that way generates the traceback shown.

40

Would someone kindly provide some insight into where the exact specifications of the registry were discussed, and what it is intended to cover? At the moment, I’m trying to understand the advantages of utilizing such a registry over a straightforward GitHub/GitLab repository, where it seems relatively simple to report bugs or submit pull requests.

1 Like