Separate Interfaces and provide NuGet Packages

[putschoeglwe]

First: let me thank you for open sourcing this remarkable piece of software. I have long criticized that the .net framework does not provide a simple mean to model file paths but defaults to strings instead. To Build upon this Lib I want to do the following two things:

1. I want to separate the implementation from the interface and create two projects.
2. I want to provide NuGet packages for both of them to facilitate reuse.

The separation of interfaces and implementation is a crucial point for reuse as I want to build an abstraction layer to encapsulate all system interaction (file system, envvars, time,...) that allows for easy mocking of said functionality and still use your Lib. However your implementation directly uses file system and envvar functionality. Once complete I would provide an implementation where the abstraction layer is extended to the implementation of NDepend.Path.

I am currently working on these features in my fork and wanted to get some feedback.

[ndepend]

You are welcome, we are glad NDepend.Path is useful to you. This is indeed weird that in 2015 to handle paths in .NET the proposed solution is to use strings with Path.Combine(...) ?!

Notice that separation of interfaces and implementation is not needed for mocking testing purposes, since many tests actually use the file system to test without mocking. Good luck for your fork!

[putschoeglwe]

You are right of course. I should have described more precisely what my intention is.

I first ran into the problem when trying to test time dependent code where calls to DateTime.Now occur. I encapsulated these calls and then thougth about the underlying problem: all calls to system resources. When asking google i found that for file system access there is already a lib called System.IO.Abstractions on github. What i now plan is to make NDepend.Path compatible with such an implementation and vice versa. but the problem is that i would get a mutual dependency that wont build. (System.IO.Abstractions would need the interfaces of NDepend.Path, and NDepend.Path the Abstraction Interfaces of System.IO.Abstractions).

I have had such problems before and the reason was that the implementation was shipped with the api. To break such a circular dependencies one has to separate them.

i will give it some more thought how to solve this problem with as few changes as possible.

are you interested to see NDepend.Path published as NuGet on NuGet.org? if yes then i would generate a NuGet spec and provide it for prior review as well as post the NuGet once approved by you.

[ndepend]

Thanks for your explanations,

are you interested to see NDepend.Path published as NuGet on NuGet.org? Sure please do so, I have tons of work to do next months so I am not sure I can dedicate much time to approve your work, but it would be great.

[putschoeglwe]

i just created a pull request where i added a nuspec file and filled in some information i took from the project description. if you are ok with the contents i will upload a nuget and symbolpackage to nuget.org.

[putschoeglwe]

i just wanted to let you know that i did publish a nuget package to nuget.org. see https://www.nuget.org/packages/NDepend.Path/1.0.0

[ndepend]

Awesome! We just tweeted about his,

ndepend@ndepend https://twitter.com/ndepend

NDepend.Path published as a NuGet package! https://www. nuget.org/packages/NDepend.Path/1.0.0 ... https://t.co/Nucr5GHrwk 0 retweets0 favorites Reply Retweet Favorite More

On Wed, Apr 15, 2015 at 5:55 PM, verinus [email protected] wrote:

i just wanted to let you know that i did publish a nuget package to nuget.org. see https://www.nuget.org/packages/NDepend.Path/1.0.0

Reply to this email directly or view it on GitHub https://github.com/psmacchia/NDepend.Path/issues/1#issuecomment-93410424 .