I hear your frustration and I know it well. When I started with this whole web thing, the browsers provided no way to view the source code. MacWeb was a revelation and taught me more in minutes than I had been able to learn in weeks.
Continue reading my commentary inline below. On Thu, Dec 25, 2014 at 10:35 AM, J. Paskaruk <[email protected]> wrote: > It's good that you brought this up, because this is actually a problem > I've had, as someone just starting out with web dev, and with coding, with > how the CMS is distributed. > Consider yourself fortunate to be coming at this in a time when packaging is much better than any previous point in Python's history to date. There is room for improvement, certainly, but Mezzanine (and Django) adhere to the current best practices for Python packaging. Django is the Framework, on top of which Mezzanine, the CMS, runs. > And Django itself is just an application written in Python. > Why, then, is Mezzanine distributed with Django subsumed into its > installer? This creates a falsely monolithic aspect to Mezzanine. I > understand the convenience, but it muddies the view. > Let's start by looking at the setup.py <https://github.com/stephenmcd/mezzanine/blob/master/setup.py#L52-L63> file, the link to which should highlight the `install_requires` argument to the `setup` method of the setuptools module. If you clone the repository and run `python setup.py install` at the root of the clone, the files listed in `install_requires` will be installed. The recommended `pip install mezzanine` runs `python setup.py install` behind the scenes (though it may be more complicated, I have not dug deep.) The installation process copies the files to a location on your Python path, usually into the `site-packages` directory associated with the python being called. If you use virtualenv (recommended), you create a python environment isolated from the rest of the system. I keep my virtualenvs in a hidden directory in my user directory. A new Mezzanine project might live at ~/.virtualenvs/mezzanine-project/. Within mezzanine-project, I will have access to `./lib/python2.7/site-packages/`. Note the variable version number of Python in that path! Once Mezzanine is installed, Django, Pillow, and the other `install_requires` modules will be viewable in `site-packages`. A strong word of caution: modifying files in `site-packages` will lead to pain and befuddlement! The only reason to make changes to the Mezzanine code is if you want to add features to Mezzanine to share with the rest of the world, in which case the installation method is very different! When I want to review Mezzanine code, I do it in BitBucket or GitHub. The search interfaces are good and I can easily view the history of the files. You quizzed me on irc as to whether I had done the Django tutorial. I told > you that I had, and indeed, I did it multiple times, and supplemented that > with other well-known tutorials, both Django and Rails, to solidify the MVC > concept (it is my policy, whenever possible, to have every thing I learn, > be it a practical system or an abstract concept, explained to me by three > different people/documents/videos/tutorials/whatever). The source of my > glaringly stupid errors is not that I haven't done my homework, however > that may look. > I ask everybody asking for help those same questions. On the internet, nobody knows I am a dog. And this dog has no idea what my interlocutors know. So I ask those questions in an attempt to provide answers that will make the most sense based on the level of knowledge and experience. You are doing great, and I relish the opportunity to give back to the community which continues to give so much in the hopes that you will someday be in a position to give back similarly. > This is the problem I have with how Mezzanine is distributed - the Django > tutorial teaches you to think of things as having a certain type of file > structure, with a models.py and a views.py, for instance, in your project's > home dir. If you install Mezzanine, these files are not there. They > obviously are *somewhere*, but they are most distinctly *not* where the > Django tutorial told me to expect to find them. I did not, and I still do > not, know exactly how to do deal with that, because it doesn't fit into the > schema that I learned in the Django tutorial. My intention, when I learned > about Mezzanine and decided to try it out, was to install it and examine > the code, *specifically* in the context of having *just* done the Django > tutorial. But because the files were not where I expected them to be, and > because I was too new and too ignorant of about a thousand other things (at > every level - Python, Django, Linux, Abstract Programming Concepts - every > level), I was stymied. I'm working alone, with no peers, so whatever > resources are on the net are all I've got. My goal is to be able to work > straight from Django and develop complex apps of my own (and ultimately, > recreate my rather simple Blog from my own models and views - not because > it's better to do it that way, but because it's more instructive and > useful, on a personal development level, to do it that way). > Agreed! Mezzanine "hides" the files, but they don't really go anywhere. Think of it as scaffolding that enables you to get the work done. > Mezzanine doesn't just run on top of Django, it *hides* Django, and itself > for that matter, from the new user, and thus far, I haven't found a > document on the web that explains why the views.py and models.py got > hidden, and where I can find them and look them over and mess around with > them - indeed, *all* of Mezzanine's infrastructure is hidden. If this is a > structure that has been built on top of a Django framework, why can't I, > having done the Django tutorial, easily examine that infrastructure, to see > how it works? Why is the directory structure changed, and where is the > Mezzanine tutorial that explains this to newbies who have *only* done the > Django tutorial? > As stated above, reading the Mezzanine source is probably easiest in BitBucket or GitHub. Doing so provides historical context and access to the issue tracker. Django and Mezzanine are never hidden, just not particularly useful for the core activity of building an application that uses Mezzanine and Django. In particular, the activity of deploying a Mezzanine site can be done in a vacuum without knowledge of the source, and that source should never be edited directly. I realize that I can, that I only need to hunt down those views and models, > which I know are in there somewhere, but the creators of Mezzanine have > taken steps to make them hard to find for newbies. I'm sure that it makes > things a million times easier for professionals, of course, in ways that I > do not understand yet, but of which I acknowlege, and plead, my own > ignorance. > Mezzanine is a great app to read to improve your understanding of Django. If you want to understand the underlying mechanics of a blog engine, reading the Mezzanine blog app will help you on your way. For good or ill, this is covered in the Mezzanine documentation. > So, when you admonish me to check the Django docs in cases where the > problem is a Django problem rather than a Mezzanine problem, I would like > *nothing* more than to do just that, I assure you, but I'm at the "drinking > from the firehose" phase of my personal development into a developer, and I > have a hard enough time sorting out which parts are Django and which parts > are Mezzanine, *without* the fact that Mezzanine is not distributed > separately from Django in spite of the fact that it *is* separate from > Django, and indeed, is setup in such a way as to make the lines between the > two *extremely* blurry for a beginner like me. > You stumbled on SECRET_KEY and ALLOWED_HOSTS, and the tracebacks you shared were explicit in their statement of the problem. Those two are very well covered in the Django docs and the former would have given you clues as to how to approach NEVERCACHE_KEY. > I noticed, as a suggestion, that there's an IDE, Aptana I think? That's > distributed both as a monolithic app, and as a plugin to Eclipse - maybe > Mezzanine could release an "explicit" version that "plugs into" a raw > Django server, so that competent-but-ignorant folks like myself, fresh out > of Django tutorial school, could more easily recognize that line between > Django and Mezz? I've actually been trying to figure out how to find the > actual Mezzanine code for a while now, cause the way I really learn is by > messing around with stuff at that level, changing words or colour settings, > so I can just see what affects what, and after a while (after breaking and > restoring it a billion times) I get so I really know the thing. But > reaching that point is touch and go, and unfortunately, the working dev's > emphasis on "getting things done" stands in the way of actual learning, > much of the time. While I recognize the obvious advantages to these tools > like fabric and such (I'm reading the Fabric docs today), there is also the > fact that at this point in time, it is of more personal value to me to > execute each command in that fabfile by hand, so I can actually understand > the parts of the system and how they work together. Once I'm working in the > industry, I'll love that stuff, but right now it just makes it harder to > learn. > This stuff is hard to learn, and proper respect to you for endeavoring to do so. Unfortunately, you will have to get your head around The Python Way of doing things. This isn't necessarily the best way, but it should become clear with experience why The Python Way is the way it is. > Anyways, it's Christmas, so I know you're not prioritizing the revision of > your tutorial today, but in the spirit of same, I gratefully acknowledge > your patience with me, and your willingness to help out a newbie. All of > these criticisms I'm writing are intended in a spirit of constructiveness, > even if my frustration with the process occasionally surfaces in my > rhetoric. If I can successfully deploy this, in fact, I intend to document > the process myself, cause I'm actually rather good at writing tutorials, > and for now I see them as how I can start to give back to the community, > even though I still can't contribute code of any sort. But before I can > teach, I need to fully learn. I appreciate every scrap of personal > attention paid to me and my issues, just for the record. I'm here, doing > this, because (among other things) Richard Stallman is a personal hero. I > want knowledge, and I want to share that knowledge. Getting a decent job > out of the deal is also hoped for, natch, but my approach here is > meditative. > I am actually not prioritizing edits to the Vagrant tutorial at all. I am unlikely to change it because it still works and serves as a historical document. It requires some understanding of Python, Django, and Vagrant, and gaining that understanding is left as an exercise for the reader. I will continue to support you. And if you choose to write an updated tutorial based on my work, I would be very likely to link to it and would certainly thank you profusely for working to improve the collective knowledge. But my itch was scratched and revisiting it does not add value for me. I guess I'm being a bit verbose because there is an aspect to this > community where people only seem willing to help those who have > demonstrated that they have tried to learn things on their own first, and > indeed I have - the fact that my mistakes are glaring and dumb are not a > sign of inattention, but of the fact that I am learning many things in a > short period of time, including the minutiae of various languages and > protocols and systems, along with the macro picture of how fits (or fails > to fit) with the others, all using only the "Big Data" of the community's > collective output, filtered through the almighty algos of Google. It's > touch and go, and when I start a tutorial, I generally seek to mindlessly > follow as much as possible, and when I write a tutorial, I try to write it > in such a way that it can be mindlessly and successfully followed - that > is, cover every *required* step, however minimal and obvious. If it's a > keystroke that needs to be pressed in order to finish the tutorial, it > should be mentioned in the tutorial (and ideally, explained succinctly, > with a link to a deeper explanation for those who want or need to learn > more). That's what I'll be attempting to write, as soon as I have > ascertained and compiled the successful set of steps that result in a > deployed Mezzanine blog. > Looking forward to the reading the fruits of your labors. > I actually haven't even examined whether Amazon has better documentation > for Vagrant (to which you can consider me a convert). As mentioned > elsewhere, Digitalocean's Vagrant tutorial is from 2013, and even their > internal links are out of date, but the Vagrant tutorial I did successfully > deployed a Hubot to AWS, so maybe I can adapt that. Blarg. > I have no idea. I know that the fabfile deploys to AWS, DO, and RackSpace without issue for me. Vagrant is just a local stand-in for those services so I can work from the beach or mountaintop. Whatever the case, for many reasons (including some plans I have for the > Raspberry Pi), I'm intending to stick with a Python framework, and Mezz > covers all of my needs to a T, so please let me know once you figure out > that password problem we were having. No rush, I know it's Christmas. And > have a good one, if that's what you're into. I'm more of a solstice hippie > type. :> > My mom told me to "have a sexy solstice" on Sunday. Doing my best! And I hope the entire Mezzanine community does, too. -ken -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
