Closed pombredanne closed 5 years ago
Thought I responded to this back when you first opened the ticket, but something must of eaten my comment.
I'm working to add two classmethods, Pom.fromstring() and Pom.parse(). They're modeled on the lxml.etree functions of the same name. The client will be optional and we'll just forgo all of the dynamic loading of external POMs data.
I'm up in the air about whether to still require the maven coordinates. Currently those are used to set the groupId, artifactId and version without needing to parse the POM data first. Not sure how useful that is if you're working without a repository client.
The constructor of Pom is restricted because it assumes that I must know "coordinates" ahead of time https://github.com/sassoftware/pymaven/blob/3a844cd3dc10c04196ad12cdf500dde233f5a508/pymaven/pom.py#L49 And that I have effectively some repo that handles the retrieval. In my usecase for ScanCode as a possible replacement of this https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/maven.py I need to be able to parse a POM from some file path and nothing else. I do not have a "repo" nor do I know the "coordinates" yet: the whole purpose of parsing for me is to discover these....
So I am left with this alternative:
I hate 2. but I cannot see a way around this? @wfscheper what do you think?