[Dev] Decouple Path.py

[Kausikram Krishnasayee]

I recently hit upon a problem [  http://blog.kausikram.in/?p=288 ] while using paver / python27 on a windows XP machine which had lead me to do some digging into Paver's version of path.py

A diff against path.py 's head [ https://raw.github.com/jaraco/path.py/master/path.py] showed that the changes made in Paver's version to avoid dryrun issues were very small. [it boiled down to wrapping path.py APIs around a paver function that will execute the actual file operation on a real run and not on a dry run] 

Now considering that path.py has been receiving updates offlate would it not be better to decouple it off paver, and make it a dependency and make paver.path use a caller into path.py.

I have branched of paver and started doing exactly this. But what i wanted to know was, is this a conscious design decision to leave path.py inside paver instead of making it a dependency?    

[Kevin Dangoor]

Including path.py was a conscious choice at the time. Back in 2008, no one was maintaining path.py, so it was more pleasant to make Paver dependency-free and just include the dry-run changes directly.

I have no opinion on what should be done now...

Kevin

--
You received this message because you are subscribed to the Google Groups "paver" group.
To view this discussion on the web visit https://groups.google.com/d/msg/paver/-/NjVouOe9BRoJ.
To post to this group, send email to pa...@googlegroups.com.
To unsubscribe from this group, send email to paver+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/paver?hl=en.

--
Kevin Dangoor

work: http://mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Almad]

Hi,

when I was reviving path two years ago, it looked relatively unmaintained, I am glad it changed.

However, I am kind of worried about removing bundled dependencies; some of them changed much in the meantime and would present quite a regression for users (i.e., I recently updated cog, discovered that newest version is unusable and newest-1 require minor patch for some of paver use-cases). OTOH, dependency handling also improved a lot, so I maybe it's worth the shot, but I wonder if it should not be paver 2.0 then (now with modular dependencies and more ice cream).

In any case: if you would provide a patch that would use external paver.py without regression, I would gladly use apply it if it would use bundled path.py version as fallback.

Thanks,

Almad

Dne sobota, 14. července 2012 8:07:51 UTC+2 Kausikram Krishnasayee napsal(a):