* status: new => closed
* ui_ux: => 0
* resolution: => wontfix
* easy: => 0
Comment:
I buy that there are reasons why someone might prefer to store relative
paths instead of absolute paths. But ultimately, this is an internal
implementation choice; providing options for everything just makes Django
more confusing to use. This added option in the documentation would be one
more thing any new user picking up FilePathField for the first time would
have to understand and make a decision about. For those who really want
relative paths, the code in the patch for RelativeFilePathField can live
outside Django core and work just fine.
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by sandychapman@…):
The only problem being this being closed is that wiki link posted in the
comments is broken. So now, for those who come to this page when looking
for a relative path solution (without using just a plain old CharField or
TextField which will have no path validation or drop-down selection box on
the admin page) they will have nothing. TBH, relative paths are much more
useful than absolute paths as, like others have noted, the development box
is not usually (and shouldn't be) the same as the deployment box. I could
run a VM on my dev box which has the same paths as my deployment box, but
I shouldn't have to. This requires scripts to be written to modify every
row in the db, when something as simple as a flag could be added to the
FilePathField which tells it to solely store the relative path.
E.g.
Instead of
{{{
file_source = models.FilePathField(path='C:\workspace/path/to/filestore/',
recursive=True)
}}}
you could have
{{{
file_source = models.FilePathField(path='C:\workspace/path/to/filestore/',
recursive=True, store_relative=True)
}}}
Just have this flag default to {{{False}}} and you remove the
justification you've given for closing this issue as won't fix. Users
setting up databases won't be anymore confused about having an extra
option in the model construction as they already are with having that
option missing. They'll be wondering, "how do I make this relative path?"
then spend 10 minutes Googling for a solution only to find that the Django
devs deemed it too confusing for them. In any case, these people are
likely developers who should know what they're doing anyway.
Sorry for the rant, I just completely disagree with why this issue was
closed and think the feature detailed would be a nice improvement.
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:12>
Comment (by chris.case@…):
I don't understand the fear of adding an option. !FilePathField already
has several, and they already have defaults. A new user doesn't have to
make a decision if the core development team's already made it for him.
That's the point of providing sane defaults, something django's extremely
good at.
One of the things I love about django is it's "Batteries Included"
approach. In this regard, the ability to store relative paths should be a
no-brainer. What's more (maybe I'm just special, but...) I've never once
wanted to use a !FileFieldPath with an absolute path. All my use cases
have required it to be relative (since I'm typically pre-populating the
database with fixtures, and deploying on a different machine than I
develop on). It's finally annoyed me enough to come comment on this
ticket.
Personally, I don't think you give your users enough credit. "relative
paths" aren't a crazy concept that only the Computer Elite can fathom...
it's a basic consideration that crops up often in web development. Grab a
random django newbie, and ask them if you want; I'll bet you 20 bucks that
they don't stumble on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:13>
Comment (by secret24@…):
I think an option for storing relative paths would be a good thing... I
even would set it to default behaviour... If i want to save a location of
a file into database, i would still like to be able to take my project to
another server without breaking all those paths....
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:14>
Comment (by zanuxzan):
Replying to [comment:11 carljm]:
> I buy that there are reasons why someone might prefer to store relative
paths instead of absolute paths. But ultimately, this is an internal
implementation choice; providing options for everything just makes Django
more confusing to use. This added option in the documentation would be one
more thing any new user picking up FilePathField for the first time would
have to understand and make a decision about. For those who really want
relative paths, the code in the patch for RelativeFilePathField can live
outside Django core and work just fine.
I can't see how this logic holds true - like others have stated, there are
already a number of options for FilePathField and this is not any harder
to understand than the other options, in fact, I imagine most users would
be used to the behaviour of FileField, which is stored as relative.
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:15>
Comment (by zanuxzan):
For anyone who is interested, I have taken the patch above and created
django-relativefilepathfield.
Project is on bitbucket.org: https://bitbucket.org/alexhayes/django-
relativefilepathfield
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:16>
Comment (by Bernd Wechner):
I'll just and a voice of thanks to Alex Hayes for making a package
available and one in critque of the justification I read from Carl Meyer
which I also find does not hold water on jot. Django is littered with
configurable options and RelativeFile paths are not useful in 'some'
circumstances, but likely IMHO a lot, relative in particular to the
BASE_DIR of the website (for files stored there, and databases that want
to remain portable between different BASE_DIRs and not have file paths in
these fields become erroneous.
--
Ticket URL: <https://code.djangoproject.com/ticket/6896#comment:17>