Future breaking API changes

[eminence]

This issue is collecting some ideas for breaking API changes that we might want to make in the future

• Convert some fields from Option<T> to T if they were added in very old kernels (#68)
• Remove stat and pid fields from the Process struct to support cases when you don't need this information (#60)
• Remove some deprecated methods (#52)
• Returning ticks in CpuTime (#76)

[madjokr]

Hi, I just started using this library. First off, it's a fantastic library. I am using this library to build a service that's going to be deployed around 1000+ instances. My app uses PID field to monitor the process. If you are removing this option, will there an alternative way to find process PID through this library? Sorry for sending a message this late.

[eminence]

Hello! I'm glad to hear that this library is useful to you!

The proposal in #60 is to just remove the pid field. So you can still get access to the PID information via the stat() method. For example, to get the PID of the current process:

let me = procfs::process::Process::myself().unwrap();
let my_pid = me.stat().unwrap().pid;

(This code works today, too).

Does that answer your question?

[lparcq]

Hello, The time returned in procfs::CpuTime should be a number of ticks in u64 as it is for processes in procfs::process::Stat. It's better to be able to get the values as returned by the kernel.

[Nukesor]

I'm just in the process of removing all clippy warnings and adding clippy checks.

This involves replacing a lot of manual prefix removals by the new strip_prefix method. Since this method has been added in Rust 1.45, this would certainly remove support for 1.33 and 1.38 versions.

I guess this could be considered a breaking change.

An alternative would be to simply ignore these clippy warnings.

[uggla]

Hello,

First thank you writing this lib this is really useful. I'm a contributor of the scaphandre project (https://github.com/hubblo-org/scaphandre) and we use procfs. The project currently uses version 0.8.1. and we noticed that 0.9 introduced major breaking changes. So before bumping and changing the code, we would like to know if the api is stable enough right now, as most of the issue in this ticket seems closed. Or if you still have plan to to introduce new breaking changes ?

[eminence]

Hi @uggla :wave:

The short answer is: the API can still change in incompatible ways in a future 0.10.x release. I don't consider the API stable enough for a 1.0 release yet. (In fact there's an open draft PR that is proposing a breaking change). However in practice, the API breaking changes tend to be fairly small, and not that often.

I saw the comment you made in the scaphandre repo, so I'll also make a comment over there to talk about any specific issues related to your project.

[eminence]

This issue hasn't been updated in a long while, so I'm going to close it. We've been doing breaking changes in new minor versions, and this has been working well for us for a while. Thanks all