Instantiate Specfile with a string

[danishprakash]

Description

Currently, it's possible to do this via a file path. In my use case, all I'm doing is fetching the specfile for multiple packages via OSC API and then trying to parse them using Specfile. I'm currently creating a temp file and then passing it on to the package.

Is this something that can be supported or have there been any discussions in the past about this that ruled it out?

Benefit

No response

Importance

No response

Workaround

• There is an existing workaround that can be used until this feature is implemented.

Participation

• I am willing to submit a pull request for this issue. (Packit team is happy to help!)

[nforro]

This should definitely be possible, let me think about implementation.

[danishprakash]

That's great, let me know If I can help with this.

[lachmanfrantisek]

Still relevant. @danishprakash by any chance, would you be interested in contributing this? (We can definitely help.)

[p0tat0chip]

is the usage something like mentioned in #206 ?

[danishprakash]

My idea is to be able to create an object by passing in a string, this is assuming I have a string buffer with the specfile contents. #206 seems to be suggesting to allow a file handle to be passed to to the constructor.

[p0tat0chip]

What i think is the string can be passed from a method with the sourcedir argument from_str(spec_content) like:

spec_content = """\
Name: example
Version: 1.0
Release: 1%{?dist}
Summary: Example Package
"""
specfile = Specfile.from_str(spec_content, sourcedir="/abc")

the method will take string buffer and write to a tempfile to maintain the file behaviour that returns a path and avoid touching parts
like save() and reload() since they operate on files and expect path to be present.
sourcedir will be required.
This is just the same as the workaround.

[nforro]

Wouldn't it make more sense to first implement #206 and then use a StringIO instance internally and initialize it with a given string?

[p0tat0chip]

Yeah, that's why i had a thought if #206 is somehow related. If this approach is alright i can work on it.