Should I use the default environment to use my library?

Question

I had this discussion with a friend where I have a library (its python, but I did not include this as a tag, since the question applies to any language), which has several dependencies. The discussion is whether to provide a default environment during initialization or force the user of the code to explicitly install it.

My opinion is to get the user to be explicit and to avoid confusion and make it clear what they are pointing to.

My friend, it is safer and more convenient by default for the environment and allows the user to override if he wants.

Thoughts? Are there any good links or examples / templates in popular libraries that support any of our arguments? Also, any popular blogs or articles discussing this API design point?

Answer 1

I have no links, but here are my thoughts as a potential user of the specified library.

I think it's nice to have a standard configuration that allows developers to quickly evaluate the library. I don’t want to go through a bunch of configurations to see if the library will do what I need. As soon as I am glad that the library will do what I need to do, then I will be happy to configure it the way I want.

A good example is the Microsoft ASP.Net MVC framework. When you create a new MVC project, it connects to the default authentication and membership provider, which allows the developer to launch a working application very quickly. It is also easy to configure the various providers that will be used if, by default, they do not meet the requirements of the application in question.

As a slightly different example, Atlassian Confluence is a wiki software that supports many different databases. Atlassian may not have selected the default database configuration, but instead, Confluence sends a standard, simple file database that allows users to evaluate software. For production installations, you can connect to Oracle, SQL Server, mySQL, or whatever you like.

There may be times when the default configuration configuration for the library does not really make sense, but I think this will be a special case, not a general rule.

Answer 2

It depends. If you can provide reasonable defaults, you can do it: it will make life easier for the casual library user, since they can only set the appropriate settings, unlike the whole environment (with possible settings, the consequences of which they do not understand everything (yet)). You are right that this is possible in situations, which leads to disappointment and confusion, since the default settings can cause unexpected behavior (unexpected for the (inexperienced) user) - you should weigh the reduced frustration of convenience compared to the price of the obscure default values to make a selection for each of these possible default settings, the selection of which may affect the selection for other related parameters, and

On the other hand, if there is no reasonable default value (for example, database credentials, remote address), you should require the user to provide these settings.

The key in both cases is to provide sufficient information in the library documentation and in error messages (either for missing parameters or in conflicting ones) that the user can determine what these parameters actually mean / control, without having to read through the source code libraries. This part is difficult because 1) it is usually tedious from the point of view of the library developer (therefore, it is often shortened), and 2) the documentation should be written from the beginner’s mindset to the library, which is often different from the mentality of library developers - the latter knows implicit connections / consequences , the first should be said about this in an understandable way.

Answer 3

Although this is not completely identical from the point of view of the problem area, it looks like the Conformation over configuration argument.

Over the past years, there have been many impulses in CoC, and, in my opinion, this makes a lot of sense. As long as flexibility is not lost, you have everything to win. The development of lower friction is what we're all after, and if I need to configure every aspect of your API to make it work, I'm less likely to use it on another API of equal functionality.

I like Hanselman podcasts, so if you want to listen to some light, check out this podcast .

Answer 4

I think your question needs clarification. For starters, I don't think the library should have any run-time configuration. In terms of dependencies, library dependencies should be handled in a way that matches the environment in which they are written. In python, these dependencies must be in the setup.py file (as required), and ultimately this file must meet the requirements of any service that you plan to make available (e.g. pypi for python).

For applications, it’s fine to require runtime settings, but you should try to have reasonable defaults. If your application depends on libraries, this dependency should be handled in the same way as library management, even if this information may be redundant in the context of the installer (if necessary). For the most part, the first scripts and their files should be separated by the installer / rpm.

For web frameworks, it is typical that your application will carry the configuration with it and you will probably need to install it in a different way than traditional applications. Here, the only thing you can do is try to comply with the agreements of any structure in which you write.