Note: This website is archived. For up-to-date information about D projects and development, please visit wiki.dlang.org.

Ticket #109 (closed enhancement: fixed)

Opened 12 years ago

Last modified 12 years ago

Need a way to specify an alternate dsss.conf

Reported by: baxissimo Assigned to: Gregor
Priority: minor Milestone: 0.71
Component: DSSS Version:
Keywords: Cc:

Description

There should be some way to specify an alternate dsss.conf file. Sometimes you just want to experiment with a different way of building or whatever. In those cases being able do say dsss -f alt-dsss.conf build would be nice.

-f is the flag used by GNU make. It doesn't really matter what dsss uses for it, but it would be nice to use -f if possible due to many people being familar with make.

Change History

(follow-up: ↓ 2 ) 08/13/07 15:24:42 changed by Gregor

  • priority changed from major to trivial.
  • status changed from new to assigned.

I often reject requests because, while they're perfectly legitimate, I feel that they would or could encourage bad design. I have received and rejected this request one or two times before for that exact reason.

While your reason for wanting -f is totally legitimate, and I understand why that would be helpful, I have an intense fear of reading this in a README.install:

If you're using GNU/Linux, type dsss -f dsss.conf.linux build. If you're using Windows, type dsss -f dsss.conf.windows build.

While of course making this change wouldn't make that necessary, I feel that newbies would be inclined to fall into that hole.

So, the strategy I recommend for testing dsss.conf files is to deploy them in a "testing" directory or similar, and then ask people who are testing them to copy them in for the actual testing procedure. A kluge? Yes. But by making it a kluge, I'm basically guaranteeing that nobody's going to fall into the trap of using it where it shouldn't be used.

However, I'm not going to close this without giving you a chance to defend your position. So, post a response, explain what you think would be best as a compromise.

(in reply to: ↑ 1 ; follow-up: ↓ 3 ) 08/13/07 21:03:06 changed by baxissimo

Replying to Gregor:

I often reject requests because, while they're perfectly legitimate, I feel that they would or could encourage bad design. I have received and rejected this request one or two times before for that exact reason.

I think that if you really want to provide a useful tool to the community you have to accept that different people will find different ways to user your tool. You can certain have a style guide and try to encourage people to do things "the right way" and castigate anyone who does things improperly, but in the end it's the user who has to decide what works best for them. There's no point in being a software "Soup Nazi".

While your reason for wanting -f is totally legitimate, and I understand why that would be helpful, I have an intense fear of reading this in a README.install: {{{ If you're using GNU/Linux, type dsss -f dsss.conf.linux build. If you're using Windows, type dsss -f dsss.conf.windows build. }}}

Denying a -f doesn't really make something like that all that much less likely:

If you're using GNU/Linux, copy dsss.conf.linux to dsss.conf. If you're using Windows, copy dsss.conf.windows to dsss.conf.

While of course making this change wouldn't make that necessary, I feel that newbies would be inclined to fall into that hole.

Well tell 'em not to then.

So, the strategy I recommend for testing dsss.conf files is to deploy them in a "testing" directory or similar, and then ask people who are testing them to copy them in for the actual testing procedure. A kluge? Yes. But by making it a kluge, I'm basically guaranteeing that nobody's going to fall into the trap of using it where it shouldn't be used.

I don't understand the logic there. Seems like the opposite would be true. If it's always called "dsss.conf" it seems like you would be more likely to accidentally use the wrong one, and/or accidentally check in dsss.conf.test as dsss.conf.

However, I'm not going to close this without giving you a chance to defend your position. So, post a response, explain what you think would be best as a compromise.

Two suggestions: 1) make the flag be something long to type so that people really have to think about whether that's what they want to do. Something like '--config-file='. 2) make "dsss -help" say '(use sparingly)' or '(not recommended)' or something after listing the flag to specify an alternate file.

(in reply to: ↑ 2 ; follow-up: ↓ 4 ) 08/13/07 22:42:23 changed by Gregor

  • priority changed from trivial to minor.
  • milestone set to 0.72.

Replying to baxissimo:

Replying to Gregor:

I often reject requests because, while they're perfectly legitimate, I feel that they would or could encourage bad design. I have received and rejected this request one or two times before for that exact reason.

I think that if you really want to provide a useful tool to the community you have to accept that different people will find different ways to user your tool. You can certain have a style guide and try to encourage people to do things "the right way" and castigate anyone who does things improperly, but in the end it's the user who has to decide what works best for them. There's no point in being a software "Soup Nazi".

There's a fine line I'm walking here. With make, for example, because it's so helpful to developers, it's often confusing and obnoxious for end users. Remember, I'm a F/OSS guy, so I'm looking at this from a F/OSS perspective: Not only are the people building the software not necessarily the people who wrote it, they aren't even necessarily developers. I want, therefore, absolute standardization for the end-user experience, even if that means making the developer's experience a bit more constrained. I realize that's not a good way to get developers to use DSSS, but the motivation is sound.

... especially when the end user is dsss net install. That guy isn't very capable of figuring things out on his own.

While your reason for wanting -f is totally legitimate, and I understand why that would be helpful, I have an intense fear of reading this in a README.install: {{{ If you're using GNU/Linux, type dsss -f dsss.conf.linux build. If you're using Windows, type dsss -f dsss.conf.windows build. }}}

Denying a -f doesn't really make something like that all that much less likely: {{{ If you're using GNU/Linux, copy dsss.conf.linux to dsss.conf. If you're using Windows, copy dsss.conf.windows to dsss.conf. }}}

I find it pretty unlikely that that would actually be somebody's standard method. Having -f sort of encourages this IMHO.

While of course making this change wouldn't make that necessary, I feel that newbies would be inclined to fall into that hole.

Well tell 'em not to then.

I find that telling people what to do and what not to do works about 0% of the time :)

So, the strategy I recommend for testing dsss.conf files is to deploy them in a "testing" directory or similar, and then ask people who are testing them to copy them in for the actual testing procedure. A kluge? Yes. But by making it a kluge, I'm basically guaranteeing that nobody's going to fall into the trap of using it where it shouldn't be used.

I don't understand the logic there. Seems like the opposite would be true. If it's always called "dsss.conf" it seems like you would be more likely to accidentally use the wrong one, and/or accidentally check in dsss.conf.test as dsss.conf.

Now that's an excellent point.

However, I'm not going to close this without giving you a chance to defend your position. So, post a response, explain what you think would be best as a compromise.

Two suggestions: 1) make the flag be something long to type so that people really have to think about whether that's what they want to do. Something like '--config-file='. 2) make "dsss -help" say '(use sparingly)' or '(not recommended)' or something after listing the flag to specify an alternate file.

How about this: dsss --help says it's not recommended for general use, and actually using it outputs a nag warning to this affect. I think people would be discouraged enough from using it to alleviate my fears then.

I'll slate that for 0.72.

(in reply to: ↑ 3 ) 08/14/07 00:02:49 changed by baxissimo

Replying to Gregor:

Replying to baxissimo:

Replying to Gregor:

I often reject requests because, while they're perfectly legitimate, I feel that they would or could encourage bad design. I have received and rejected this request one or two times before for that exact reason.

I think that if you really want to provide a useful tool to the community you have to accept that different people will find different ways to user your tool. You can certain have a style guide and try to encourage people to do things "the right way" and castigate anyone who does things improperly, but in the end it's the user who has to decide what works best for them. There's no point in being a software "Soup Nazi".

There's a fine line I'm walking here. ... I want, therefore, absolute standardization for the end-user experience, even if that means making the developer's experience a bit more constrained.

Ok. I can kinda see that. So one should think of dsss as more like autoconf/automake in that sense. It makes life easy for the end user if not for the developer.

... especially when the end user is dsss net install. That guy isn't very capable of figuring things out on his own.

Got it.

While your reason for wanting -f is totally legitimate, and I understand why that would be helpful, I have an intense fear of reading this in a README.install: {{{ If you're using GNU/Linux, type dsss -f dsss.conf.linux build. If you're using Windows, type dsss -f dsss.conf.windows build. }}}

Denying a -f doesn't really make something like that all that much less likely: {{{ If you're using GNU/Linux, copy dsss.conf.linux to dsss.conf. If you're using Windows, copy dsss.conf.windows to dsss.conf. }}}

I find it pretty unlikely that that would actually be somebody's standard method. Having -f sort of encourages this IMHO.

I've see that exact setup in plenty of open source projects. Makefile.win32, Makefile.borland, etc. along with the recommendation to copy the one that applies to "Makefile". Can't think of any particular projects off the top of my head, but I've definitely seen it multiple times.

While of course making this change wouldn't make that necessary, I feel that newbies would be inclined to fall into that hole.

Well tell 'em not to then.

I find that telling people what to do and what not to do works about 0% of the time :)

Well, it's not your responsibility to be their nanny in the first place, so if they want to ignore your advice, then let 'em. But when they come asking you to make their code available via dsss net, that's when you'll tell em to fix it or forget it.

How about this: dsss --help says it's not recommended for general use, and actually using it outputs a nag warning to this affect. I think people would be discouraged enough from using it to alleviate my fears then. I'll slate that for 0.72.

That sounds perfect. It won't deter people from making their own little side test projects, but it will still strongly encourage people to keep the main-line deployable stuff in the main dsss.conf.

08/14/07 21:13:44 changed by Gregor

This is going to be a bit easier than I anticipated, so I'm moving it to 0.71.

08/14/07 21:13:59 changed by Gregor

  • milestone changed from 0.72 to 0.71.

Try #2: Actually moving it to 0.71 >_>

08/15/07 04:02:56 changed by Gregor

  • status changed from assigned to closed.
  • resolution set to fixed.

I changed this to --config=<name> to make it a bit more consistent with the rest of DSSS' options. Added in revision 768. Closing.