Show deprecation warning for Data Packages created with previous versions of frictionless

[peterdesmet]

Fix #293.

@sannegovaert this should resolve issues you had with river_telemetry and o_assen while frictionless 1.2.1.9000 was loaded.

You can test with:

library(frictonless) # Installed from this branch
movepub::o_assen # Should show deprecation warning
movepub::o_assen # Should just show print, since warning is only shown once

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (cc4f8c3) to head (51ae001).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #294   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           23        23           
  Lines          658       667    +9     
=========================================
+ Hits           658       667    +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[peterdesmet]

All functions should work on older packages, that is currently not the case:

• print()
• resource_names()
• read_resource()
• write_package()
• add_resource()
• create_package()

library(frictionless)
p <- movepub::o_assen

p
#> Warning: `package$directory` was deprecated in frictionless 1.3.0.
#> ℹ This Data Package was created with an older version of frictionless. Read or
#>   create it again to avoid this warning.
#> ℹ The deprecated feature was likely used in the frictionless package.
#>   Please report the issue at
#>   <https://github.com/frictionlessdata/frictionless-r/issues>.
#> This warning is displayed once per session.
#> Call `lifecycle::last_lifecycle_warnings()` to see where this warning was
#> generated.
#> A Data Package with 2 resources:
#> • reference-data
#> • gps
#> For more information, see <https://doi.org/10.5281/zenodo.10053903>.
#> Use `unclass()` to print the Data Package as a list.

resource_names(p)
#> [1] "reference-data" "gps"

read_resource(p, "reference-data")
#> Error in `purrr::map_chr()` at frictionless-r/R/resource.R:60:7:
#> ℹ In index: 1.
#> Caused by error in `check_path()`:
#> ! Can't find file at 'O_ASSEN-reference-data.csv'.

write_package(p, "o_assen")
#> Error in `purrr::map_chr()` at frictionless-r/R/resource.R:60:7:
#> ℹ In index: 1.
#> Caused by error in `check_path()`:
#> ! Can't find file at 'O_ASSEN-reference-data.csv'.

add_resource(p, "iris", iris)
#> A Data Package with 3 resources:
#> • reference-data
#> • gps
#> • iris
#> For more information, see <https://doi.org/10.5281/zenodo.10053903>.
#> Use `unclass()` to print the Data Package as a list.

create_package(p)
#> A Data Package with 2 resources:
#> • reference-data
#> • gps
#> For more information, see <https://doi.org/10.5281/zenodo.10053903>.
#> Use `unclass()` to print the Data Package as a list.

^{Created on 2026-04-13 with reprex v2.1.1}

[peterdesmet]

@sannegovaert @PietrH we have two options when a user has stored a Data Package object (e.g. as an rda) created with an older version of frictionless. Which one do you prefer?

Option 1

1. When loading/printing on old Data Package object, the user gets deprecation warning:

   package$directory was deprecated in frictionless 1.3.0.
   ! This Data Package was created with an older version of frictionless
   ℹ Create a valid Data Package object with read_package() or create_package().

2. The object is converted to the latest version, meaning:

• They won't get the deprecation warning anymore
• All other frictionless functions will work

or:

Option 2

1. Same as above
2. The package is not silently converted to the latest version, meaning:

• They won't get the deprecation warning anymore (because they are silenced by lifecycle)
• The user has to manually run my_package <- create_package(my_package) (the deprecation warning could make this clearer)
• If they don't, not all frictionless functions will work

---

The decision also has future implications: with frictionless v2, we might want to upconvert other aspects. The question is whether this should be done by check_package() (silently) or create_package() (on purpose, by the user).